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1.0 SUMMARY 

The Industry Liaison Section is a new function of the Army/NASA Aircrew-Aircraft Integration 
Program that is intended to bridge an existing gap between Government developers (including 
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contractors) and outside organizations who are potential users of products and services developed 
by the A 3 I Program. Currently in its 6th year, the Program is experiencing considerable pull from 
industry and other government organizations to disseminate products. Since the A 3 I Program's 
charter is exploratory and research in nature, and satisfying proper dissemination requirements is in 
conflict with the rapid prototyping approach utilized by the design team, the A 3 I Program has 
elected to create an Industry Liaison Section to serve as the Program's technology transfer focal 
point. This report describes the process by which the Industry Liaison Section (ILS) may be 
established, organized and managed, including the baseline organizational structure, duties, 
functions, authority, responsibilities, relationships and policies and procedures relevant to the 
conduct of the ILS. 


2.0 INTRODUCTION 

The A 3 I Program began development in 1985 as a joint project funded by the U.S. Army, located 
within the Computational Human Engineering Research Office at NASA/Ames Research Center. 
The Program's objective is to devise a rational, predictive methodology for aircraft cockpit design 
that integrates human factors engineering with other vehicle design disciplines (including training 
implications) at an early stage in the development process. The technical approach is to utilize off- 
the-shelf computer hardware with standard operating systems and languages (UNIX, C, Common 
LISP) in the development of prototype software tools, which are the essential products of this 
R&D effort. The methodologies employed include rapid prototyping, in cre mental software 
development and object-oriented programming. The approach and methodologies chosen are 
consistent with the requirements for Army R&D level funding, but may fall short of requirements 
for use of these software products outside the developing organization. There is also the potential 
for significant gaps between the user community's needs and the capabilities under development by 
the Program design team. Lastly, there is a greater emphasis on leveraging existing staff through 
cooperative relationships with organizations that are performing similar research or who are 
actively involved in the use of computational human factors design techniques. The ILS charter is 
to aid the bidirectional flow of technology between the A 3 I Program and other organizations by 
facilitating transfer of software products to industry as well as providing feedback to the Program 
design team regarding current needs of the user community. This document was developed to 
provide guidelines for ILS staff members during the ELS’ formation and initial operations. 


3.0 MANAGEMENT 

3.1 Organization 

Figure 1 is a toplevel organization chart beginning at the Center level. Details of the Computational 
Human Engineering Research Office, including the result of a recent reorganization of FLI/YBI, 
appears in Figure 2. This reorganization establishes a government position titled Project Manager 
for User Liaison and several support staff positions. 


3.2 Organizational Interactions 

The ILS Project Manager will ideally be a government position, while ILS staff members may be 
either government or contractors. The projected scenario for staffing the ILS organization is a 
NASA or Army Project Manager and ILS staff from the Software Support Task 216 contractor 
(Figure 2). 
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3.2.1 Project Manager 

The Project Manager will report directly to the Chief, Code FLI/YBI. ILS requirements may 
be dictated to the Project Manager by the Branch Chief or A 3 I Deputy Director. Input to 
requirements may be provided by Principal Scientists, Software Support or Program 
Support, but implementation is subject to approval by the Branch Chief or A 3 I Deputy 
Director. 

To facilitate open, efficient and effective interactions between the ILS and outside 
organizations, the Project Manager should be a government position. This avoids any real 
or perceived conflict that may arise if the Project Manager were contract personnel when 
interacting with industry on potentially sensitive topics. Interactions with outside 
organizations include industry, other government agencies or NASA centers and academia. 
The ILS manager will generally make initial (with respect to the ILS) contact with an 
organization, followed by more detailed interactions by ILS staff members, as appropriate. 

Assuming ILS staff are provided by the Software Support Task 216 contractor, the Project 
Manager will interact on a regular basis with the Task Manager to apprise the manager of the 
performance of ILS staff. Any difficulties with ILS staff should be directed to the Task 
Manager if personal consultation proves ineffective. The Project Manager will also discuss 
staffing requirements with the Task Manager to aid the Task Manager in effectively using 
their company recruiting resources. The Project Manager will participate in interviews (after 
first level screening) of prospective contractor employees for assignment to the ILS. Staffing 
will be discussed in more detail in the Staffing Section. 

The Project Manager will work closely with the PSTA Manager in identifying, defining and 
implementing the policies and procedures assigned by FLI/YBI. These may include 
configuration management, quality assurance, reliability and documentation. 

The Project Manager will establish and maintain communications with the NASA TU office, 
appropriate legal representatives and NASA Headquarters to ensure dissemination and receipt 
of products conforms to current NASA (and Army) policy. The Project Manager may 
delegate routine interactions with NASA TU and NASA COSMIC to ILS staff, but will 
continue to monitor these interactions. 

The Project Manager may be required to interact with public relations professionals in cases 
where technology transfer is the prevailing topic and increased FLI/YBI visibility is 
desirable. It may be appropriate for the Project Manager to establish communications with 
the NASA external relations office and other organizations to explore the possible benefits 
and side effects of increasing public exposure to FLI/YBI developments. 


3.2.2 ILS Staff 

ILS staff will report to and receive technical direction, assignments and responsibilities from 
the ILS Manager. Staff may have additional reporting responsibilities if the positions are 
filled by contractor personnel. ILS staff are likely to be supplied by either the software 
support or PSTA contract, although potential organizational conflicts might be avoided if the 
ILS support staff and software support staff are from the same organization. For this reason 
it is recommended that the software support contractor supply ILS staff, to be 
administratively (monthly report input, personnel issues, company policy, etc.) managed by 
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the Software Support Task Manager . ILS staffing levels below the Project Manager will be 
dictated by activity, future directions, facilities and funding limitations. 

One key area of interaction for ILS staff will be direct contact with outside organizations who 
are evaluating MIDAS technology or are under consideration by FLT/YBI for collaborative 
work. Examples of common interactions include: 1) support Project Manager during 
preliminary interactions with outside organizations, 2) support Project Manager and FLI/YBI 
during in-house demonstrations of MIDAS, 3) follow up on technical issues surrounding 
possible collaborative efforts or technology transfer 4) serve as the focal point for support of 
visiting staff who are evaluating MIDAS technology and 5) instigate dissemination of 
software and documentation following the necessary approvals. 

It will be the responsibility of ILS staff to be intimately familiar with the principles, 
functionality, limitations, and certain implementation aspects of MIDAS software 
components. Close interaction with software support staff will be necessary to achieve this 
and maintain current knowledge of development status. 

ILS staff who are responsible for investigating and understanding the range of relevant 
design tools and techniques employed outside FLI/YBI will also be required to convey this 
information clearly and concisely to development staff members. The nature and regularity 
of these interactions will be dictated by FLI/YBI and ILS management. 

ILS staff will also work closely with PSTA staff in areas such as configuration management, 
quality assurance and maintainability. ILS staff will assist with development and 
implementation of standards, policy and procedures in these areas. Familiarity with 
documentation and reporting standards which may by mandated by FLI/YBI through PSTA 
staff is required. 

To anticipate future technology transfer requirements, other staff interactions may include 1) 
consultation with Chief Scientists regarding ongoing and future research areas and 2) 
interaction with researchers outside FLI on topics ot immediate interest to the Branch. 


3.3 Responsibilities 

This section describes in general terms some of the key responsibilities of the ILS collectively. 
Assignment may be distributed across several staff member and overlap in many instances. The 
staffing section contains a more complete and specific breakdown of skills and responsibilities of 
individual ILS staff members. 


3.3.1 Technology Assessment 

ILS staff will continuously survey other government sites, industry and academic institutions 
to assess the state of design aiding tools and techniques applicable to the MIDAS approach. 
Examinations may include systems and techniques ranging from highly mature and functional 
products to laboratory-base prototype systems inspired by recent research. ILS management 
and staff will study this technology and generate summary reports and recommendations as 
outlined in the Reporting Section below. 
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3.3.2 Technology Transfer 

One of the most important functions of the ILS is to facilitate the transfer of technology from 
FLI/YBI to other government sites and industry, and to encourage collaborative agreements 
with outside organizations who have something of value to contribute to A 3 I. Policy and 
procedures for dissemination of software as outlined in the Policy and Procedures Section 
will be the responsibility of ILS staff. 

As part of the overall technology transfer effort, ILS staff will be responsible for preparing 
and tracking software submissions to NASA COSMIC. This represents an important step 
for organizations who wish to utilize MIDAS software without necessitating a collaborative 
or other contractual arrangement. Since the typical cycle period for software submissions is 
several months from submission to availability, proper preparation and scheduling of 
submission will minimize rework and delays. 


3.3.3 Liaison 

Closely related to the function of technology transfer is the more general responsibility of 
liaison with outside organizations. This type of activity will generally encompass both visits 
to other sites and hosting visitors within FLI/YBI for the purpose of encouraging cooperative 
work arrangements, transfer of technology, information gathering or perhaps political 
objectives. In-house responsibilities will include ongoing end-of-phase demonstrations and 
other briefings supported by the Project Manager and ILS staff as required by FLI/YBI. 
These types of interactions may include briefings before or after a demonstration and 
narration during the demonstrations. 

In addition to direct contact with outside specialists, ILS staff will remain cognizant of 
industry and government techniques and tools through publications. ILS staff will monitor 
technical publications and other relevant documents for indications of trends, state-of-the-art 
and breakthroughs in technology or techniques. 

Although liaison with outside organizations has been emphasized, the importance of 
maintaining good relations and effective communications with management and in-house 
staff cannot be underestimated. The information collected, summarized and disseminated by 
the ILS is virtually useless if it does not reach the proper personnel or if it is considered of no 
value by the recipients. Consequently, there must be a clear communications path between 
the ILS and development staff, coupled with clear support for ILS activities from the 
FLI/YBI or Program Office level. 

Other liaison-type activities such as liaison with NASA TU, legal offices and public relations 
were mentioned previously in the interaction sections. 


3.3.4 Planning 

Offsite: The A 3 I Program holds a yearly offsite meeting to evaluate the results of a previous 
development phase and plan the subsequent one. This meeting typically spans several days 
and includes participation by project management, development staff, support staff, 
contractors and invited expens whose perspective is considered of value in planning the next 
development phase. Planning, conducting and summarizing these olfsite meetings is a 
considerable task which has traditionally benetited from participation by individuals outside 
the immediate development, management and support staff. The ILS will be responsible for 
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recommending to the offsite planning team industry and other government participants for the 
eminent offsite meeting. Upon acceptance by the planning team, the ILS will be responsible 
for issuing invitations and following up with accepted individuals. Other support for the 
offsite may be provided by the ILS as necessary 


3.3.4. 1 Phase Planning 

The user community will play an increasingly large role in the direction of future A^I 
development phases. Since the ILS is most closely tied with this group, technical 
planning for each development phase will require participation by ILS staff. 


3.3.4. 1 Budget Planning 

The yearly budget plan prepared by PSTA staff may in future phases include funding 
contributions or projected contributions from industry and other government agencies. 
The ILS will keep PSTA staff apprised of the status of any existing or pending 
agreements which may affect budget planning. 


3.3.5 Demonstrations 

Yearly end-of-phase demonstrations are conducted to apprise the user community, potential 
funding sources, management, technical specialists and other interested personnel of the 
status of MIDAS. Demonstrations represent a sizable time investment and detract 
significantly from development, but are essential to continued funding for R&D type 
programs. Nonetheless, considerable efficiency, effectiveness and improved development 
staff morale could be achieved by offloading the major portion of demonstration support to 
ILS staff. The reasoning is that software engineers are most effective developing software, 
while ILS staff (probably composed of managers, human factors specialists and engineers 
who appreciate the opportunity to discuss problem solving techniques) have been recruited to 
perform liaison functions that require refined communications skills. Other benefits include: 

More global picture 
More cohesive presentation 

Less likelihood of centering too heavily on implementation details 

Sensitivity to real problems 

Examples of real-world MIDAS applications 

The vast majority of demonstrations could be supported by ILS staff. In cases where a 
particular domain expert is required or implementation details are of primary concern, one- 
on-one interactions could be individually scheduled so that unrelated development efforts are 
not affected. 


3.3.6 Reporting 

An important product of technology transfer and liaison activities within the ILS will be the 
generation and distribution of status and summary reports. The reports will be used by 
FLI/YBI and Program Management to maintain up to date knowledge of 1) outside research 
and development, 2) areas and level of interest in FLI/YBI products, 3) status of ongoing 
cooperative agreements and 4) MIDAS user feedback. This information may be 
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subsequently used by management to assess the current and future directions of research and 
development in FLI/YBI. A more detailed breakdown of ILS reporting requirements is 
contained in the Documentation subsection of Policy and Procedures. 


3.3.7 Staffing and Startup 

The Project Manager will be responsible for implementation of the ILS under the direction of 
FLI/YBI management. This document will serve as a preliminary guide, but is expected to 
evolve as the needs of the ILS change. The Project Manager's duties will initially encompass 
the entire spectrum of tasks outlined in this document, although prioritized as necessary and 
subject to the immediate requirements of FLI/YBI. 


3.3.8 Other 

Additional responsibilities of the ILS will be determined by Code FLI/YBI and A 3 I Program 
Management. These may include periodic support for special in-house events, participation 
in professional conferences and other direct support activities. 


4.0 POLICY AND PROCEDURES 

4.1 Configuration Management 

Since A 3 I is primarily a research oriented Program, numerous organizational and technical barriers 
exist at this time which affect efficient flow of software technology into and from the ongoing A^I 
Program development effort. One major area of concern for the ILS with regard to technology 
transfer is software configuration management. Generally, configuration management for research 
projects is significantly less structured and policies loosely enforced due to the prototypical nature 
of most developments. However, as code becomes more stable and interest increases outside the 
A^I, it becomes critical that some form of configuration management be implemented and 
followed. 

4.1.1 Definitions 

Baseline: A collection of software and corresponding documentation formally designated 
and fixed at a specific time during a Configuration Item's life cycle. Baselines, plus 
approved changes, constitute the current configuration. 

Configuration Control: The systematic evaluation, coordination, approval or disapproval, 
and implementation of all approved changes in the configuration of a Cl after formal 
establishment of its baseline. 

Configuration Item (Cl): An aggregation of hard ware/ soft ware, or any of its discrete 
portions, which satisfies an end use function and is designated for configuration 
management. 

Configuration Management (CM): A discipline applying technical and administrative 
direction and surveillance to (a) identify and documenting the functional and physical 
characteristics of a Configuration Item (Cl), (b) control changes to those characteristics, 
and (c) record and report change processing and implementation status. 
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Discrepancy: A note showing variance between what exists and what is documented to 
exist or considered acceptable. 


4.1.2 Problem Description 

The complexity of large scale, long-lived software development efforts such as A^I 
increases in a roughly exponential manner with time as the overall size of the system 
grows. This tendency stems from a number of well known software engineering factors, 
including: a growth in the number of functions, components, and interfaces; the expansion 
of old routines for uses beyond their original design; the problem of new developers 
implementing parts of the system before they fully understand how it works; and a loss of 
institutional memory as original developers leave. These types of problems are 
compounded in a distributed environment where mismatches in old and new software can 
occur on individual systems, or new software (operating system, framework applications, 
etc,) releases can introduce inconsistencies. 

The growing complexity in the Man-Machine Integration Design and Analysis System 
(MIDAS) cannot be stopped. However, software development practices can be adopted 
that slow the rate of growth to an acceptable level. A critical element of these practices is a 
software source control system to manage the introduction of new versions of software 
applications and a configuration management plan to control the distribution of software. 

The software configuration related tasks encountered by the A^I Program in controlling 
software versions and providing application programs developed in-house to outside 
organizations are likely to include the following activities: 

Maintenance and Bug Fixes 

Technical Phone Consultation 

Non-Technical (user) Phone Consultation 

Distribution Tape Generation 

Configuration Tracking 

Release Logging and Tracking 

Release Notes Generation 

Software Update Distribution 

Software/Hardware Configuration Documentation 

User's & Programmer’s Documentation 

Documentation Updates 

Testing and Verification 

Government Tech Transfer Requirements 

Many of the above tasks could be eliminated by the issuing organization if code is provided 
on an "as is" basis, without support. However, close collaborative working relationships 
are often desirable and cannot work effectively under such circumstances. Consequently, 
some form of configuration management must be implemented that is compatible with the 
development methodologies (incremental software development, rapid prototyping, etc.) 
that are presently in use by A^I designers. The CM system must also address version 
control of the wealth and variety of existing software systems in a manner that does not 
adversely affect new development or limit exploratory work. 

This section is intended to serve as an outline for a portion of an overall configuration 
management plan that is tailored for the A^I Program and similar research and development 
programs. Initial emphasis will be placed on the details and characteristics of each major 
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software component that comprises MIDAS, followed by specific software CM tool 
recommendations that may be utilized immediately to begin version control. This document 
is not intended to serve as a comprehensive CM plan, since its focus is primarily on CM 
issues as they affect technology transfer. 


4.1.3 A 3 I Software Application Programs 

The A 3 I Program to date has produced or funded the development of nine major software 
components that are presently an integral part of MIDAS, and about three stand alone or 
support programs. Individual components are called Computer Software Configuration 
Items (CSCI). Since the products under development by A 3 I are primarily software 
applications, CSCIs may be referred to as simply Configuration Items (Cl). The CIs are 
listed in Appendix A, including brief descriptions, native language and hardware platforms, 
versions, documentation, any configuration management systems that may be used at this 
time and the level of interest known or projected to exist outside A 3 I. Some information is 
missing such as dynamic memory requirements. 


4.1.4 CM Recommendations 

4. 1.4.1 Planning 

The A 3 I Program's consideration of production issues for certain mature software 
application areas will require a simple, effective plan which is recognized by all staff levels, 
especially software development personnel, as important. This plan outline is proposed 
as a platform for discussion among Program and support staff management, to be followed 
by consultation with remaining staff. The goal is to converge on an approach that satisfies 
the need to control software configurations without adding a level of bureaucracy that 
excessively hinders development progress or discourages innovative thinking. 


4.1.4.2 Organization 

The existing A 3 I organizational structure is sufficient to plan, implement and adapt an initial 
set of CM policies and procedures that is appropriate for the A 3 I Program and like efforts. 
However, as the A 3 I Program reaches the final phases of exploratory development, it will 
be desirable to add full time staff to perform CM and software maintenance functions. 


4. 1.4. 3 Responsibilities 

It is recommended that implementation of configuration management policy and procedures 
be the responsibility of the Programmatic Support and Technical Assistance (PSTA) 
contractor, with input from the ILS and A 3 I Program Office. PSTA will provide status 
reports to the Program Office on a regular basis initially, .and an as-needed basis after CM 
procedures have been sufficiently adopted. Provisions will be made to allow modification 
and adaptation of policy and procedures as the needs of A 3 I change. 

It will be the responsibility of the cognizant ILS staff member to understand current 
procedures and interact the the System Administrator as necessary to maintain an up to date 
understanding of the status of both hardware and software configurations for all major 
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software components of MIDAS. The ILS staff member will understand the variations of 
hardware platforms and software configurations which may affect the suitability of 
potential user's hardware and software for installation and execution of MIDAS 
components. A sample form is included below to aid the ILS staff member in documenting 
and tracking configurations of MIDAS software. 

Software Configuration Table 


Software Module 


Release Current Platform 

Version Version 


Jack 




Mission Spec./Task Decomp. 




Pilot Model 




Training Assessment 




Cockpit Editor/Views 




Communications 




Aero/Guidance 




Volumetric FOV 




Visibility 




Visual Modeler 




Icon Editor 




Modeler 





Figure 3. Software Configuration Table, 


The ILS will be responsible for assessing the suitability of any adopted CM policy and 
procedures for technology transfer activities that are part of ILS charter. Close interaction 
with the PSTA contractor will be necessary ■ > ensure initial CM policy and procedures, as 
well as modifications and adaptations, are compatible with the needs of the ILS. 

The A^I Program Office will oversee the development and implementation of CM policy 
and procedures. Final decisions regarding alteration of established CM policy will be made 
by the Program Office. Staffing requirements beyond the current complement will be 
evaluated by the Program Office to determine if additional CM personnel are warranted. 


A 3 I software development and support staff will be responsible for 1) participating in the 
initial development of CM policy and procedures, 2) adhering to the established procedures 
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and 3) providing feedback to PSTA and ILS management on the effectiveness or 
applicability of those procedure currently in effect. 


4. 1.4.4 Policy Directives 

The A 3 I Program Office will delegate authority to the PSTA contractor to develop, enforce 
and modify CM policy and procedures. PSTA staff involved with CM will consult with 
ILS staff and software development staff to promote development of a CM system that is 

compatible with A 3 I's goals and objectives. 

The ILS will be responsible for reporting to the PSTA the effectiveness of CM with regard 
to technology transfer activities. 

4. 1.4.5 CM Implementation 

The following section may be used as an outline for developing a more complete 
implementation plan for A 3 I configuration management. It provides a minimal set of 
operating procedures that can be used as interim measures until a comprehensive plan can 
be developed and exercised. 


4. 1.4.5. 1 Base Line Identification 

Each major A 3 ! software development cycle is called a Phase, typically covering from 6 
months to 1 year. At the end of each Phase, demonstrations are conducted, comments 
assimilated and planning meetings conducted to ascertain the scope of the next Phase. 
Software applications developed over the course of any Phase consist of numerous 
integrated CIs that are collectively referred to as MIDAS. The completion of a development 
Phase represents an appropriate juncture to establish a baseline, since the MIDAS 
configuration is generally frozen at that time. 

Individual MIDAS CIs are presently referenced by name (see A 3 I Software Application 
Programs Section), although early development phases also correlated module names with 
work breakdown structure (WBS) numbers. A WBS or Cl numbering scheme is 
recommended for identifying and tracking individual MIDAS application programs and 
their constituents. 

At the completion of each development Phase, a baseline will be established consisting of 
all MIDAS CIs as well as ancillary or support programs. The CIs will be identified by 
WBS or Cl number and will include a minimum of the information identified in the A 3 1 
Software Application Programs Section above. Individual CIs will be baselined as well as 
the integrated MIDAS product. 

4. 1.4. 5. 2 Configuration Changes 

Changes to any Cl or MIDAS baseline may be precipitated by software or hardware bugs, 
operating system upgrades, application program upgrades, hardware changes, critical 
software functionality improvements or other factors that make it impractical or undesirable 
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to maintain the existing baseline. The final approval or denial of baseline configuration 
changes and the classification of these changes will be through the PSTA contractor, 
however, the PSTA contractor must obtain concurrence from both the ILS manager and an 
A^I Program Office designee prior to initiating any change. Changes which require CM 
action may classified as 1) minor and 2) major releases. 


Minor: Minor changes are enhancements, upgrades, bug fixes and other evolutionary 
alterations of the MIDAS configuration or individual CIs that occur during a 
development phase subsequent to the established baseline. Minor changes typically 
have not been documented, and do not affect the baseline. CM action regarding 
minor changes involves primarily logging these changes and reporting status to 
management, although incremental documentation of minor changes will reduce the 
effort required for major releases. 


Major Releases: Major releases provide an intermediate opportunity to upgrade the baseline 
configuration without necessitating the completion and acceptance of a development 
Phase. A major release is generally an accumulation of minor changes to an extent 
that significant functionality and performance improvement has been gained. The 
major release configuration becomes the new baseline. 

Major releases primarily benefit outside organizations who are using MIDAS in 
some capacity, in addition to a diminished in-house documentation effort at the end 
of a development Phase. PSTA management and staff will be responsible for 
projecting major release dates. 

All major releases will be preceded by a complete archiving of the current MIDAS 
software configuration prior to implementation of changes (probably already 
performed as part of the completion of the previous Phase, or the most recent major 
release). The archiving will be accomplished by computer systems administration 
staff, presently under the direction of the PSTA contract manager. All 
documentation will be checked for currency to ensure it matches the archived 
configuration. Previously archived baselines will be evaluated at this time by 
PSTA, ILS and A^I Program management to determine if it is appropriate to 
continue maintaining these versions. 

Documentation will be updated upon major releases. Documentation requirements 
are likely to be less rigorous than end-of-phase requirements, and may be satisfied 
by "release note" addendum to SDDDs. Release notes will indicate the rationale 
and implementation details of any changes to the end-of-Phase baseline. 


4. 1.4.5. 3 Status Accounting 

All changes to the baseline configuration will be documented and reported. A data base 
will be established that contains all information deemed appropriate for completely 
documenting baseline configuration. The A^I Software Application Programs Section may 
contain sufficient information for an initial implementation of the CM data base. Future 
additions are likely as requirements evolve. The data base will be maintained on Macintosh 
personal computers, since these systems are most widely available and contain a broad 
range of tools to aid in the creation and maintenance of data bases. Communications 
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applications are also available to allow direct transfer of data between Macintosh computers 
and software development minicomputers. 

Changes to the baseline configuration, including minor changes that do not alter the 
baseline, will be summarized by PSTA staff and distributed in a suitable form (printed, 

floppy disk, etc.) to all A 3 ! management personnel. 


4. 1.4. 5.4 Outside Software 

The A 3 I MIDAS software configuration is composed of numerous software modules that 
have been wholly developed or modified by sources outside the in-house development 
team Currently, MIDAS contains software developed 1) in-house, 2) under subcontract 
(Bolt, Beranek and Newman, Samoff Labs, Expert EASE Systems, Analytical Mechanics 
Associates, etc.), 3) as part of a NASA Grant (University of Pennsylvania, New York 
Center for the Blind, etc.), 4) through collaborative agreements (McDonnell Douglas 
Helicopter, Software Systems, etc.) and 5) as commercial off-the-shelf products (Inference 
Corp. An, Software System MultiGen, etc.). Other sources are likely to provide code for 
inclusion in MIDAS in the future (BRL CAD, Georgia Tech. Research Institute GEST, 
etc.). As the number and size of these modules increases, the task of controlling the 
integrated MIDAS configuration will become unmanageable without some type of CM. 

Because it would be inappropriately restrictive to devise a blanket CM policy that applies to 
all code developed outside A 3 1 , it is recommended that the following characteristics be 
examined as part of any agreement which may ultimately result in new MIDAS code. The 
characteristics are presented as a set of questions that might be considered in the process of 
evaluating a software application. 

CM policy. 

Any CM used? 

If so, what system? 

If not, how is released software controlled? 

Updates. 

How are updates provided? 

How often? 

Corresponding documentation updates? 

Support. 

Hotline? 

Single technical point of contact? 

More than one technically cognizant? 

Any motivation to be responsive? 

Stability. 

How mature is product? 

How stable is sponsoring organization? 

Software. 

Cost? 

Bug free? 

Source provided? 

Well commented? 

Standard C and LISP constructs (i.e. portable)? 

Compatibility with existing hardware (i.e. memory requirements, etc.)? 
Compatibility with existing software systems? 

Documentation. 
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User documentation? 

Programmer documentation? 

Quality and currency of documentation? 

Release notes and other updates? 

License/Distribution 

Any contractual restrictions? 

Number of CPUs code permitted on? 

A^I distribution rights? 

Each application should be individually evaluated in terms of these considerations, where 
some considerations are of greater consequence than others. For example, software that is 
available in executable only form is generally disqualified. Licensed software is also 
avoided, but has been used at times where there are no alternatives to supply critical 
functional capabilities. 


4. 1.4. 5. 5 New Software Recommendations 

Since commercial and contracted software represents a sizable percentage of all A^I CIs, it 
is appropriate to adopt some minimum CM requirements for any system under evaluation 
for inclusion in MIDAS. To serve this purpose, CM will be considered from the i 

perspective of the development platform, i.e. UNIX hosts and LISP machines. It is ! 

assumed that source code is available for any A^I Cl. • 

CIs obtained externally for use under the UNIX operating system (Silicon Graphics 
workstations) should use the UNIX Revision Control System (RCS, see 5.3). Ideally, the 
developing organization will implement and maintain code under RCS, although it may be 
necessary for the cognizant technical lead within the A^I in-house staff to perform this [ 

function. Similarly, code written for LISP machines should use the Symbolics System \ 

Construction Tools (SCT). i 

New contracts (procurement contracts, grants, collaborative agreements, etc) should be 

written to include use of RCS or Symbolics Systems with any software provided to A^I. I 

This does not require much additional effort by the developer, particularly if it is new 

software, so the cost impact should be minimal. User documentation must be provided as 

part of the deliverable. Since A^I will pay for this one way or another, it is most cost 

effective to have the developing organization produce this documentation, even if it 

increases the contract cost. The cost/benefit of contractually requiring programmer's 

documentation should be analyzed on a case by case basis. 


4. 1.4. 5. 6 Existing External Software 

Software developed externally for A^I that is still undergoing development by outside 
organizations represents an area where some CM compromises may be necessary to 
minimize A^I in-house developer workload. Examples of CIs that fit this classification 
include Jack, the Volumetric Field of View Vision Model and the Visibility Vision Model. 
In these and similar instances that may arise in the future, the preferred course of action is 
to require the sponsoring organization to use RCS or Symbolics Systems. Failing this 
avenue, distribution of current releases of these applications must be the responsibility of 
the originating organization, since the A^I development team has no means of controlling 
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or tracking changes without devoting staff to the lower priority tasks of software update 
and maintenance. 


4. 1.4.5. 7 Software Released to COSMIC 

The Computer Software Management and Information Center (COSMIC) is NASA's 
clearing house for Government developed software that is of widespread applicability. All 
A 3 I applications which qualify for submission to COSMIC (see Software Technology 
Transfer Contractor Report, August, 1989) will ultimately become available publicly via 
COSMIC. However, COSMIC is able to provide only the submitted version and 
accompanying documentation, since no mechanism exists (except another complete 
submission cycle) for providing updates. Consequently, it is likely that requests for 
upgrades may be handled directly by A 3 1 for recipients of COSMIC software. 


4. 1.4.6 Controls 

To ensure the planning and implementation of CM policy and procedures continues to serve 
the changing needs of A 3 I, suitable controls are necessary. These controls, however, 
should not interfere with the objective of the A 3 I Program; exploratory development. The 
system of controls would be counterproductive if it in any way discourages developers 
from making improvements or fixing known software deficiencies. At the same time, staff 
must understand the importance and long term benefits of adopting and consistently using 
software CM. 

There are two primary development platforms presently used by A 3 I software engineers: 1) 
UNIX-based processors and 2) LISP machines. Both platforms have built-in tools to 
document and control configurations of large software systems. 


4. 1.4.6. 1 UNIX Configuration Tools 

The two most common UNIX CM tools are the Source Code Control System (SCCS) and 
the Revision Control System (RCS). SCCS is a source management system that originated 
at the University of California at Berkeley and is available on 4.x BSD variations of UNIX 
systems. It maintains a record of versions of a system, including what changes, why they 
were made, who made them and when. RCS is a similar system that originated in the 
Department of Computer Sciences at Purdue University. Because RCS is considered a 
more powerful and general purpose software management system, it is recommended as 
the preferred tool for use with UNIX systems and will be described in greater detail. 


RCS: The following description is taken from the UNIX Programmer's Supplementary 
Documents, Volume 1, Section 13. 

The Revision Control System (RCS) manages multiple revisions of text files. RCS automates the 
storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised 
frequently, for example programs, documentation, graphics, papers, form letter, etc. It greatly increases 
programmer productivity by providing the following functions. 
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1 . RCS stores and retrieves multiple revision of programs and other text. Thus, one can maintain 
one or more releases while developing the next release, with a minimum of space overhead. 
Changes no longer destroy the original -- previous revision remain accessible. 

a. Maintains each module as a tree of revisions. 

b. Project libraries can be organized centrally, decentralized, or any way you like. 

c. RCS works for any type of text: programs, documentation, memos, papers, graphics, VLSI 
layouts, form letters, etc. 

2. RCS maintains a complete history of changes. Thus, one can find out what happened to a module 
easily and quickly, without having to compare source listings or having to track down colleagues. 

a. RCS performs automatic record keeping 

b. RCS logs all changes automatically. 

c. RCS guarantees project continuity. 

3. RCS manages multiple lines of development. 

4. RCS can merge multiple lines of development. Thus, when several parallel lines of development 
must be consolidated into one line, the merging of changes is automatic. 

5. RCS flags coding conflicts. If tow or more lines of development modify the same section of code, 
RCS can alert programmers about overlapping changes. 

6. RCS resolves assess conflicts. When two or more programmers wish to modify the same 
revision, RCS alerts the programmers and makes sure that one change will not wipe out the other 
one. 

7. RCS provides high-level retrieval functions. Revision can be retrieved according to ranges of 
revision numbers, symbolic names, dates, authors, and states. 

8. RCS provides release and configuration control. Revision can be marked as released, stable, 
experimental, etc. Configuration of modules can be described simply and directly. 

9. RCS performs automatic identification of modules with name, revision number, creation time, 
author, etc. This, it is always possible to determine which revision of which modules make up a 
given configuration. 

10. Provides high-level management visibility. His, it is easy to track the status of a software project 

a. RCS provides a complete change history. 

b. RCS records who did what when to which revision of which module. 

1 1. RCS is fully compatible with existing software development tools. RCS is unobtrusive - its 
interface to the file system is such that all your existing software tools can be used as before. 

12. RCS' basic user interface is extremely simple. The novice only needs to learn two commands. Us 
more sophisticated features have been tuned towards advanced software development environments 
and the experienced software professional. 

13. RCS simplifies software distribution if customers also maintain sources with RCS. This 
technique assures proper identification of version and configurations, and tracking of customer 
changes. Customer changes can be merged into distributed version locally or by the development 
group. 

14. RCS needs little extra space for the revisions (only the differences). If intermediate revisions are 
deleted, the corresponding differences are compressed into the shortest possible form. 


4. 1.4.6. 2 LISP Machine Tools 

The Symbolics LISP machines used by A^I software developers include a utility known as 
the System Construction Tool (SCT) that is designed for building and maintaining 
applications composed of a large number of source and executable files. 


Symbolics System Construction Tool 

Symbolics software developers can define a "system" as any set of files, rules and 
procedures that define the relations among these files. A system can include LISP source 
files as well as files written in other languages such as FORTRAN or PASCAL. A 
system is defined using an SCT defsystem special form that is called a system declaration. 
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The system declaration specifies the names of the source files (or modules), the desired 
operation (compile, load, both) for each file and any dependencies. After a system has 
been defined, executing the command Load System <sysname> causes the operating 
system to automatically load into dynamic memory the proper executable files in the proper 
sequence. Any necessary update such as a recompile and load of a changed file is 
automatically performed, also resulting in the necessary updates to any changed file version 
numbers that comprise the system. 

Incremental changes to the system are easily provided by the patch facility. The patch 
facility allows software developers to avoid recompiling or reloading an entire system after 
changes have been made by maintaining a directory of incremental file changes. It is also 
makes it possible to maintain multiple versions of the same system. 

Many A 3 I applications residing on Symbolics hardware are presently using a manual 
variation of the SCT which requires the developer to construct a text file (generally called a 
"loadfile") that contains the name and explicit executable version number of each file in a 
system. The loadfile does not contain implicit dependencies (executable files are loaded in 
the order listed) or facilities to automatically compile and load changed files. It is the 
responsibility of the software developer to update the loadfile after any change has been 
made to the system. While this method has proven efficient for relatively small, 
prototypical applications, it is not recommended that this approach be utilized with large, 
relatively stable systems that may be distributed outside A 3 I due to the maintenance and 
tracking difficulties. 

It is highly recommended that the Symbolics System Construction Tools be utilized for all 
major software applications that execute on Symbolics equipment. Systems ultimately 
save a considerable amount of time for applications composed of numerous different files 
with complex file dependencies. Several examples exist on A 3 I hardware which may be 
used as patterns for new systems. 

4. 1.4.7 Verification 

It may be desirable to encourage adherence to CM policy and procedures by periodically 
conducting audits and reviews to verify the status of any current or previous MIDAS 
configuration. An audit of any major software component should require no more than 2 
hours to verify the type of information listed under the A 3 I Software Application Programs 
Section. It will be necessary, nonetheless, to impact the work schedule of the cognizant 
software engineer or engineers for this relatively brief period of time. The verification will 
be conducted by the PSTA manager or designee. Results of the verification will be 
reported by the PSTA contractor either as a discrepancy report or conformance statement. 
A sample Software Configuration Audit form is provided (Figure 4). 
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SOFTWARE CONFIGURATION AUDIT 


Auditor 

Software Engr. 


Software Name 


WBS Number 


Applications & Version 


Languagc(s) 


Hardware Platform(s) 


OS Version in Use 


Latest Hardware OS Version 


Baseline Version & Date 



Major Release Version & Date 


Development Software Version 


Last Minor Update 

















Another forum for verification of MIDAS configuration data is the regularly scheduled 
technical status reviews required by the Program Office. These reviews represent an 
effective mechanism for CM verification, provided there is advance notice of the topic and 
attendees have an opportunity to prepare. 


4. 1.4.8 CM Summary 

As the A 3 I Program continues to grow and transition to mature, production stages of 
development for certain elements, software related tasks will change from development to 
maintenance and rapid prototyping to highly structured methods under strict configuration 
management. A comprehensive plan for configuration management would include 
treatment of engineering change proposals, deviations, waivers, priorities, change control 
board, quality assurance provisions, critical component identification, audits, 
configuration status accounting and configuration traceability to name a few. A large 
amount of published material is available on "standard" CM within the Government that 
may be referenced when the A 3 I Program reaches the stage where rigorous CM is required. 
Until that time, it is nonetheless desirable to devise and implement an appropriate subset of 
CM practices that are compatible with the present emphasis of A 3 1. 

The A 3 I Program is composed >f a number of support organizations whose responsibilities 
vary from software development to budget planning. For example, the software 
engineering and PSTA staff are not from the same contractor organization. This situation 
represents a potential conflict in the area of CM, since the PSTA contractor will in effect be 
"managing" another contractor by conducting audits and requiring compliance with CM. 
The key to making CM work for A 3 I is adopting sensible policies and procedures that are 
recognized as valuable, and that in the long run reduce developer workload. CM for the 
sake of CM will not work for a program like A 3 ! unless there is a shift in emphasis from 
development to production. 


4.2 Reliability 

The primary issue with regard to reliability is operational reliability of application software, since 
hardware is off-the-shelf and generally under commercial maintenance contract to ensure 
continuous operation. The nature of R&D efforts necessitates secondary emphasis on reliability of 
prototypical software. Because the Branch's activities are exclusively R&D, reliability issues are 
not generally addressed and no formal policy exists for disposition of known failure risks. 
However, it is recommended that the ILS take a lead role in conjunction with the System 
Administrator in proposing reliability policy and procedures. Minimally, known reliability risks 
should be documented and logged. 

The cognizant ILS staff member will coordinate with the System Administrator regarding hardware 
and software issues which may affect the reliability of existing software configurations. These 
include hardware upgrades, operating system revisions, application software updates and other 
changes to stable hardware-software configurations. 


4.3 Quality Assurance & Maintainability 

Quality assurance and maintainability policies, like reliability, are typically nonexistent in an R&D 
environment. Nonetheless, it is feasible to develop guidelines for software engineers to consider 
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whenever new software is generated or existing software is modified. Several broad guidelines 
are suggested here: 

Liberally Commented Source Code: Provide header comments (name, date, description, any 
restrictions, etc.), procedure/function description, variable meanings throughout source 
files. 

Style: Proper indentation. 

Appropriate Variable Scoping: Minimize the use of global variables. 

Modularity: Break code into manageable subparts, < 2k lines per file. 

Minimize Hardware Dependent Optimizations: Applies especially to graphics code. 

The tradeoff decisions inherent in development versus pilot or production coding must be dictated 
at the Branch or Program level, but recommendations and implications may be passed from the 
programming staff to these levels via the Task Manager. The ILS may provide input to the Branch 
or Program level from the user's perspective. 

While these recommendations are largely applicable to MIDAS software engineers developing 
code, it is important for ILS technical staff to have an awareness of these issues while evaluating 
outside software for possible collaborative arrangements. A thorough analysis of existing code's 
suitability for integration in MIDAS should include quality assurance and maintainability 
considerations. 


4.4 Joint Development 

Throughout the previous 4 years of directed software development for the A^I Program, the 
software engineering team and contracted staff have produced a considerable amount of code in the 
process for the current generation of MIDAS. Some of the code has resulted in relatively mature 
application programs, which have often been of interest to outside organizations who wish to make 
use of A^I developments as pan of their own design aiding tools. This section discusses the 
methods by which user modifications to, and joint development of prototype A 3 I software can be 
accommodated, shared, and controlled to mutually benefit both A^I and the using community. The 
section will also propose guidelines for negotiating the exchange of software, equipment, 
documentation and ideas between A 3 I and potential users, for those applications which are not 
addressed by the provisions of COSMIC. 

4.4.1 TVIechanisms 

This section covers the methods and mechanisms currently available to the A^I Program 
for use in establishing and maintaining joint development agreements with both users and 
co-developers of MIDAS and MIDAS-like products. Joint development involves a 
commitment from both parties to supply manpower and equipment resources toward the 
development of application or support software for human-machine system design and 
analysis. Each category of user/developer (i.e. Government, Industry, University ) is 
unique in terms of the most effective and appropriate methods that may be utilized, 
consequently, they will be covered separately. 

The report does not cover unilateral agreements where the Government supplies software to 
another organization without compensation (i.e. through COSMIC or Freedom of 
Information) or the Government acquires software from an outside organization through 
procurement contracts, Grants or SBIR awards. It also does not address Joint Endeavor 
Agreements, which are designed primarily for space ventures involving Shuttle 
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experiments. The orientation is toward joint development agreements and user evaluations 
that do not involve the exchange of funds and are applicable to A 3 I research and 
development activities. 


4.4. 1.1 Government 

The A^I Program to date has been supported entirely by Federal Government (DoD) R&D 
funding. This fact makes exchange of products with other Government organizations 
generally the easiest and quickest form of technology transfer available for software 
products that have no distribution restrictions imposed. As described in the Software 
Technology Transfer Contractor Report (STTCR), there are several mechanisms that can be 
used for Government-Government cooperative agreements: 

1) Memorandum of Agreement (MO A) 

2) Memorandum of Understanding (MOU) 

3) Interagency Agreement (LA A) 

Other mechanisms require the exchange of funds (Procurement Contract, Grant) are 
specific to space-related work (JEA) or involve universities (Joint Enterprise, University 
Consortium). Those involving universities will be treated in the Universities Section. 

JEAs and Cooperative agreements are typically employed when dealing with organizations 
outside the government, and will be addressed in the Industry Section. 

The Memorandum of Agreement is a Space Act agreement that has been used successfully 
within a single agency or branch of the Government when an expeditious, informal 
agreement is desired that can be generally covered by brief descriptions. The sample MOA 
in Appendix B was designed for collaboration between the A^I Program Office and a 
NASA/Ames branch. Approval was granted at both the Division and participating branch 
levels, although complete execution of the agreement requires review by legal and approval 
at the director level. It is recommended that the MOA be utilized for any collaborative 
efforts with NASA/Ames or collocated Army organizations. 

Another informal mechanism is the MOU, which primarily outlines and establishes that A^I 
and a particular organization wish to enter a relationship with the intent of negotiating a 
complete agreement at some point in the future, although a subsequent formal agreement is 
not required. MOUs are bilateral Space Act Agreements designed for use with industry', 
universities and nonprofit organizations. MOUs are typically implemented through the TU 
Office (if technology transfer is involved), reviewed by the patent counsel and approved by 
the Center Director. A^I approval has historically been granted at the Army (Code Y) and 
NASA (Code F) Directorate Levels prior to legal review. A sample MOU is provided in 
Appendix C. The use of MOU-type agreements is recommended for any collaboration 
where informal, flexible terms are suitable for both participating organizations, and a MOA 
is not applicable. This will typically occur when an informal agreement is desired between 
two Government organizations that are not located at the same geographic site. 

IAAs are designed to facilitate collaboration between Government entities. As with MOUs, 
MOAs and other Space Act agreements, there is no exchange of funds. IAAs tire likely to 
be used when a more specific and binding agreement than an MOA or MOU is desired 
between two Government organizations. An IAA would be an appropriate mechanism to 
utilize when a cooperative agreement is desired between A-^I and the FAA, DOE, or other 
branch of the Government where there has not been prior activity. 
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When developing MOA, MOUs or IAAs, it is important to realize that distribution rights 
may be an issue that should be explicitly addressed with regard to newly developing and 
existing software. The Joint Development Guidelines Section treats this issue in more 
detail. 


4.4. 1.2 Industry 

1) Memorandum of Understanding (MOU) 

2) Technical Exchange Agreement (TEA) 

3) Cooperative Agreement 

Although MOUs have been applied largely to Government-Government relationships, it is 
permissible to establish MOUs with profit-making entities as well, provided there is no 
exchange of funds. 

TEAs involve relatively specific and formal terms between two organizations and include 
the transfer of technology between the participating organizations. TEAs must be routed 
through the TU Office and approved by the NASA Patent Counsel and Center Director. A 
TEA should be utilized in cases where either party prefers a less open-ended approach than 
an MOU. Large aerospace firms are likely to require the TEA mechanism due to corporate 
restrictions or management policy. A sample TEA is provided in Appendix D. 

Cooperative agreements are one of 3 federally standardized methods (contract, grant, 
cooperative agreement) to carry out procurement activities. Cooperative agreements permit 
Government agencies to provide compensation in both monetary and non monetary form 
for efforts that require close working relationships. Cooperative agreements within NASA 
have traditionally been for research projects with universities, and must be approved at 
Ames by the Acquisition Division University Affairs Branch. This mechanism is likely to 
require the most effort and time to complete the approval cycle. 


4. 4. 1.3 University 

1) Ames University Consortium Program 

2) Ames Joint Enterprise 

3) Cooperative Agreement 

The University Consortium Program is a mechanism that allows university faculty and 
students to work with Ames personnel on short-term research projects. The participating 
university must be one of about 136 approved universities. This mechanism is 
recommended both as a means of evaluating potential staff and of acquiring short-term 
support for development efforts. It also serves as a useful means of infusing new ideas 
and approaches into the Program and establishing outside contact and visibility. 

Unique to Ames, the Joint Enterprise for Aerospace Research & Technology Transfer is a 
tripartite R&D agreement whereby the resources of Government, industry and university 
combine to transfer technology to commercial applications while simultaneously leveraging 
federal R&D resources and university research. Funding to sponsor university research 
and support Joint Enterprise (a non-profit 

organization administering the agreement) are normally supplied by either NASA or 
industry, and paid directly to the Joint Enterprise for dissemination. Each agreement is 
negotiated uniquely in terms of resources and rights (intellectual property, patents, etc.). 


24 


1 1 i Jill il IllllilJU Uli III HlllltillllUlliijliMtlJil.il. li ililllllflit I 



Cooperative agreements are as described in the Industry Section. 


4.4.2 Joint Development Recommendations 

This section describes the two most common collaborative interactions between A 3 I and 
outside organizations, 1) Joint Development and 2) User Evaluations. Guidelines and 
considerations will be proposed for negotiating agreements in each instance. It is assumed 
that the desired mechanism (MOA, MOU, TEA, etc. ) has been selected, and that the terms 
and content of the agreement are the main concern. 


4.4.2. 1 Joint Development 

Joint development agreements involve the modification or generation- of MIDAS elements, 
including activities contributing to integration of MIDAS components. Joint development 
requires the commitment of software engineering resources by both organizations toward 
the common goal of developing state-of-the-art man-machine interface design and analysis 
systems. Some of the more critical issues to be considered in a cooperative development 
agreement are described in the following section. 


4.4. 2. 1.1 Agreement Guidelines 

Term: Generally, a period of at least 1 year is sufficient to justify the effort to implement a 
formal agreement, but short enough that a long term commitment doesn't result if 
for some reason the relationship does not develop as desired. If a long term 
relationship is anticipated, the agreement should be written such that renewal at the 
end of each year is a relatively simple process (signature memo, etc.). 

Technical Suitability: In evaluating the suitability of an organization, some obvious 

characteristics include technical knowledge and available resources. The availability 
of proposed resources and any contingencies should be understood since R&D 
efforts or non revenue producing activities often receive lower priority when 
resources are scarce. 

It may at times be appropriate to enter into a cooperative agreement with an 
organization because it is politically suitable, but no recommendations are provided 
for these cases since the Program Office will have the greatest insight into the 
benefits and pitfalls. 

Scope: In defining the scope of work to be performed, be realistic. Although it is 

sometimes better to ask for more than one expects to receive, this same strategy can 
at times yield no results at all if each element is integrally tied. It is perhaps best if 
both parties know fairly explicitly what is required from each organization as part of 
the agreement. Schedules are desirable as well to avoid 80% of the work 
performed in the last 20% of the agreement period. If possible, decompose the 
work to be performed into separable, "deliverable" elements that can be 
incrementally evaluated and integrated. 

Less rigidly defined agreements may be appropriate when the objective is primarily 
exchange of existing software, rather than new code development. In these cases, 
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it would be desirable to build in a considerable amount of flexibility to cover the 
possibility of follow-on agreements. 

Rights: The A-*I Program must have the right to distribute code resulting from any 

cooperative agreement in at least binary form. Submission of executable code to 
COSMIC must be permitted. 

Sensitive or proprietary material should be clearly identified and noted in the 
agreement. 

Participating organizations should have the right to distribute approved code 
developed at Government expense throughout the organization's site, but not 
throughout the Agency or Corporation without permission from the A^I Program 
Office. These restrictions are consistent with NASA COSMIC and Freedom of 
Information Act mandates. 

Version Control: Any new software developed by outside organizations as part of a 
cooperative effort must adhere . j A^I software configuration management 
procedures for UNIX and LISP machine code development. Namely, RCS must 
be used with applications developed for UNIX hosts and Symbolics System 
Construction Tools must be used with LISP hosts. These requirements may be 
waived if the amount of code is deemed sufficiently small. 

Conventions: Some form of coding convention that is consistent with other MIDAS 

software would be desirable when new software is to be developed. For example, 
software written for UNIX hosts should include prefix identifiers for global 
variables and functions that allows other programmers to determine the associated 
module. Software Systems' guidelines would be a reasonable starting point for C 
code. LISP applications or routines may be assigned their own Symbolics 
"package" to reduce the risk of variable conflict. 

Source Code: Any new software developed for MIDAS by an outside organization must be 
provided to A^I with source code. If the source constitutes a non-separable element 
(doesn't execute stand-alone), A^I must also have the right to provide source code 
to outside organizations as part of cooperative efforts, evaluations or applicable 
submissions to COSMIC. 

Documentation: Minimally, user documentation must be provided. Where source code is 
developed, liberal use of comments throughout the code is desirable to enable 
software engineers integrating or modifying the software in the future to efficiently 
study and understand the design. 

Integration Support: Unless the interfaces have been clearly defined and documented 

(seldom the case with rapid prototyping efforts), some level of integration support 
must be provided. It is suggested that integration support be provided in at least 2 
instances: at the midpoint of development and upon completion of the agreement. 
Integration support implies software engineering staff familiar with the code who 
travel to Ames to assist with integration until the software is fully functional within 
the MIDAS framework. 

Progress Reporting: 1 page progress reports should be exchanged each month. Regular 
progress reports serve have both political and technical advantages, since 
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management can identify successes in technology transfer while developers remain 
on top of progress and are able to better anticipate problems. 

Evaluation: As part of a cooperative development effort, it is desirable to solicit user-type 
feedback at the same time development progresses. It should be recognized, 
however, that the depth and quality of these evaluations is unlikely to match what 
would be achieved by an agreement designed specifically for that purpose. It may 
be desirable, nonetheless, to include this element as part of the agreement. 

Acknowledgements: Both organizations are likely to benefit from the visibility of 
cooperative development. There should be no restrictions on publicizing a 
cooperative agreement in general terms to the extent that no proprietary information 
is released. To the appropriate extent, all presentations, briefings, announcements, 
publications and other disseminations relating to the cooperative agreement shall 
properly acknowledge both A^I and the participating organization with regard to 
their respective contributions. 

Approvals: The approvals required by A^I are dictated by the type of agreement as outlined 
in the Mechanisms Section. In addition, agreements that include the release of 
Government-developed software may under some circumstances require 
notification of NASA TU or NASA Headquarters per NMI 2210.2A. Refer to the 
STTCR for details pertaining to criteria for notification. Dissemination of 
proprietary or restricted release software must meet the requirements of the 
appropriate organization as well. 


4.4. 2.2 User Evaluations 

The prototype MIDAS has reached a stage where it is sufficiently complete to allow the 
user community to begin use and evaluation. "Alpha" or "beta" versions of MIDAS or 
MIDAS stand alone components will be provided to suitable organizations for use and 
critical evaluation so that the A^I development team can receive valuable feedback on the 
effectiveness of their products from a user's perspective. To facilitate the dissemination of 
software to participating sites in the most expedient and efficient manner, a cooperative 
agreement is required. An MOU-type format is recommended for all agreements involving 
short-term (less than 6 months) evaluation of software. 


4.4. 2. 2 Agreement Guidelines 

Term: 1-6 month evaluations are recommended since MIDAS continues to change at a 
relatively rapid pace. Terms of longer than 6 months are not advised in general 
since a reasonable amount of time and effort is required to distribute software 
updates and documentation to beta sites. 

Scope: An evaluation agreement is a commitment to use and critique the applications that 
have been supplied. Sample problems are encouraged, the results of which should 
be provided to A^I as part of the agreement so that they may be used in-house for 
demonstration purposes. The areas of emphasis in the evaluation include 1) 
usability and 2) suitability. Usability will reflect the application program's user 
interfaces, while suitability will measure how well the application(s) are able to 
solve real problems. 
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Feedback: Feedback should be in the form of written, monthly reports, although other 
forms of communication (site visits, telephone consultation, etc.) in addition to 
these reports should be encouraged. Feedback will be provided in the two areas of 
usability and suitability. 

Summaries: In addition to regular, monthly feedback, summary reports identified as part 
of the agreement may be desirable. If a sample problem format is possible, a 
summary report should be prepared describing the problem and detailing the 
performance of A^I applications in solving the problem. 

Rights: Applications provided for the purpose of evaluation are supplied in executable only 
form and may not be reproduced or distributed unless otherwise noted. Generally, 
software is made available for installation on a single CPU or suite of processors in 
the same geographic location. Proper acknowledgments are required when 
software is demonstrated or discussed outside the recipient organization. Use of 
supplied software exclusively for commercial gain or to obtain competitive 
advantage is strongly discouraged until the availability of MIDAS products is more 
widely known. 

Software and all documentation must be returned to A^I following the evaluation 
period. All code must be permanently removed from recipient equipment and 
archived copies destroyed as part of the agreement. 

Approvals: Since evaluation agreements are likely to be largely MOUs, Branch and 
Directorate level approvals are generally required. Additional approvals or 
notifications may be required as noted previously when restricted or proprietary 
software is involved. 

Protection: It is recommended that some form of "rime bomb" routine be integrated with 
software released for evaluation to ensure that software does not proliferate. This 
will help to control the number and variety of MIDAS and MIDAS component 
versions floating around outside A^I. This is an important consideration until the 
MIDAS configuration becomes relatively stable and mature. 


4A.2.3 General Recommendations 

Number of Joint Efforts: Initially, it is recommended that a maximum of one joint 

development and two user evaluation agreement be active at any given time. Since 
it is assumed that the user evaluation agreements will result in little additional load 
to ongoing A^I activities (ILS should handle the majority of this work), the joint 
development effort will require the most attention. After the first joint development 
agreement has been implemented and in progress for a reasonable period of time, 
the degree of interaction, additional workload, coordination and other aspects will 
be more apparent. At that time it should be possible to make a relatively accurate 
assessment of the optimum number of joint efforts to conduct. The most desirable 
number of user evaluations may be adjusted at this point as well. 

Updates: Since the duration of joint development agreements will generally be one year, it 
is recommended that updates to the baseline be considered quarterly. At least one 
update (preferably the final one) should coincide with the completion of an A-^I 
development Phase. 
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It may be appropriate to evaluate each quarterly update with regard to updating the 
baseline and make the baseline change discretionary rather than mandatory. 
However, at least one update of the established baseline should occur over the 1 
year agreement term. 

Scope: It seems both impractical and unnecessary to attempt joint development that covers 
the entire MIDAS suite of applications. User needs surveys suggest that the 
majority of organizations are most interested in select aspect of MIDAS capabilities 
such as anthropometric or vision analysis, rather than the entire integration 
framework. This fact should not preclude providing the integrated MIDAS 
capability to organizations, but it may limit the degree of participation that can be 
expected in the area of developing the overall framework itself. 

Site Visits: It is reasonable to coordinate site visits with quarterly releases of updates to the 
jointly developed software. These visits could be alternated so that each 
organization must travel on 2 instances (or more, if desired) to the other site to 
install, integrate and receive software and documentation. 

POC: It is critical that each participating organization have a primary point of contact. The 
POC should be intimately familiar with details of the joint development agreement 
and should probably be the most technically cognizant staff member regarding 
details of the joint development effort (i.e. the programmer). The Software Support 
Contractor Task Manager or someone from the A^I Program Office should be the 
alternate POC. Serving as the A^I focal point for a particular joint development 
agreement should not be a full time position. If the load on the POC becomes 
excessive, this may be a signal that the balance of contributions is inappropriately 
tilted. 


4.5 Documentation 

4.5.1 User's Guides 

Documentation relating to MIDAS elements produced by the A^I Program is almost 
exclusively programmer's documentation describing implementation details of a particular 
software module. The format has been standardized, and includes a short user's guide 
section. Responsibility for generation of these documents lies with the software development 
staff, who update existing documentation on a yearly basis (approximately) to account for 
changes made during the preceding design phase. 

While programmer's documentation is sufficient for developers who intend to modify or 
integrate MIDAS source code, there is insufficient documentation available for the designer 
who wishes to simply use the system. Since ILS staff are theoretically more closely tied to 
the user community than the software development staff, it is appropriate for ILS staff to be 
involved with the generation of user documentation. It is proposed that the PSTA Manager 
will have responsibility for writing and maintaining user documentation (Technical Writer 
Position under PSTA), with support from the development staff and input from the ILS. The 
initial draft of user documentation should be produced by the cognizant software staff 
member, with subsequent revisions provided by the PSTA Technical Writer with input from 
the ILS. 
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4.5.2 Programmer's Documentation 

Cognizant ILS staff will be responsible for reproduction and dissemination of programmer's 
documentation. Programmers documentation will be generated and maintained by the 
software development staff. 


4.5.3 Papers, Plans, Summaries, etc. 

Throughout the course of the A 3 1 program a number of papers have been generated which are 
generally available for release, including executive summaries, technical papers, budget 
plans, contractor reports and other relevant material. In addition, numerous related 
publications, whitepapers, technical reports and other documents have been collected and 
compiled as part of the A 3 I library. It is the responsibility of designated ILS staff to be 
familiar with the content of the A 3 I library (except books, technical documentation and 
periodicals) and to process outside requests for copies. The designated ILS staff should be 
sufficiently familiar with library contents to recognized and recommend information which 
may be of value to collaborating organizations. ILS staff should be familiar with NASA 
reproduction services and utilize A 3 I secretarial support as necessary to accommodate 
requests for information. 


4.5,4 Hardware/Software Configurations 

The ILS will maintain a listing of available hardware/software configurations for each 
separable MIDAS component. A suggested format is provided in Figure 3, although this 
format should be expanded to include hardware and software options. 


4.5.5 Agreements 

The ILS will compile and maintain a collection of all active and inactive agreements involving 
the transfer of technology. These include but are not limited to 1) procurement contracts, 2) 
grants, 3) cooperative agreements, 4) memorandum of understanding (MOU), 5) Ames 
university consortium, 6) Ames joint enterprise for aerospace research and technology 
transfer, 7) technical exchange agreements (TEA), 8) joint endeavor agreements (JEA), 9) 
Small Business Innovative Research (SBIR) and 10) interagency agreements (IAA). 


4.5.6 Reports 

4.5.6. 1 Releases & Tracking 

The ILS will generate and update a listing of all releases of software outside the 
Branch. Included in each release summary will be a minimum of the following 
information: 


Recipient Organization 

Point of Contact & Mailing Address 

Telephone Number of Point of Contact 

Purpose 

Reciprocal Deliverable (e.g. what does the government get in return?) 
Applicable Agreement (i.e. MOU, TEA, contract, evaluation, etc.) 
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Release Date 
Target Hardware 

Model & Options 
Operating System & Version 
Released Software 
Name 
Version 

Source Releases: 

Source Files 
Executable Releases: 

Duration of Evaluation 
Documentation Provided 
Release Approvals: 

Branch 

Center Technology Utilization 
Letter to NASA Headquarters 

Other Approvals (licensed software, proprietary restrictions, 
acknowledgements, etc.) 

Forms Provided: 

Software Bug Report • 

User Survey 

Status 

The status section of the release summary may be used to periodically document the 
state of any agreement involving release of products. This section may provide some 
key insights into the effectiveness of various agreements which may be used to avoid 
potential pitfalls in future ones. It also serves to collectively document Branch 
contributions to outside organizations. 

4. 5.6. 2 ILS Status 

The role of technology transfer in R&D projects like A^l is expected increase 
significantly as programs reach more mature stages where fully functional products are 
available for use. ILS activity should eventually play a significant part in the continued 
development and evolution of MIDAS due to the contributions of outside organizations. 
As activity increases, it is appropriate to explicitly document the accomplishments of the 
ILS and status of work in progress as separate and distinct from development efforts. 
This emphasis is rationalized by NASA's charter to transfer technology coupled with 
the probability that some funding for future phases of development may be contributed 
by industry or other government agencies. 


4. 5. 6. 3 Software Discrepancy 

An important part of any development effort is establishing a consistent, responsive and 
accurate feedback channel for reporting software bugs and discrepancies. Cognizant 
ILS staff will be responsible for providing copies of software discrepancy reports to 
recipients of software and encouraging both users and software engineers to thoroughly 
test code and document any bugs. 

Bug reports will be collected and summarized for both the both Program Management 
and Software Development Task Management in the form of recommendations as 
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outlined in the next section. A sample discrepancy report form is included below in 
Figure 5. 
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DISCREPANCY REPORT 


Software Name 


Task/function being performed: 


Version 


Problem: 


File(s) being worked on: 


Stack dump (4/5 lines) if applicable: 


Process duplicatable? (yes/no) 
If yes, please state steps: 


For A3I Use: 

Cause of problem: 

Action taken (in version): 


Programmer 
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4.5.6A Recommendation Reports ___ 

The ILS will be responsible for developing, administering and summarizing user 
questionnaires for any products released. The surveys will be issued by the ILS as a 
prerequisite to releasing any code. It will be the responsibility of cognizant ILS staff to 
follow up with the recipient organization to ensure that feedback is provided. 

Information contained in user reports and bug reports will be summarized in 
recommendation reports. These reports may also contain any insight gathered as a 
result of site visits, telephone conversations, demonstrations or any other contact with 
recipient organizations. Ideally, the recommendations are to be based on equally 
weighted collective feedback from all organizations utilizing MEDAS products in an 
effort to avoid favoring a particular user and their specific requirements. It is important 
that the ILS remain sensitive to this issue and avoid appropriating resources to unique 
user problems which may result in a competitive advantage for any singular 
organization. 


4.6 Release of Code and Documentation 

One primary purpose of the ILS is to aid in the dissemination of R&D products and services for 
use outside the developing organization. Although nearly all unclassified computer programs 
developed by NASA or NASA contractors can be made available to interested domestic parties, 
there are established guidelines and procedures to be followed by both the requestor and supplier 
of computer code. Initially, ILS staff must become familiar with overall NASA software 
distribution policy (Army policy is the same) as well as policies and procedures pertaining to 
specific software modules targeted for release. A NASA/Ames Contractor Report titled Software 
Technology Transfer (August, 1989) summarizes NASA policy and procedures fo r s oftware 
distribution. An attachment to this report is available from the A 3 I Program which discusses each 
major MIDAS software module and the procedures necessary for release. It is suggested that ILS 
staff become familiar with the content of the Contractor Report and attachment. 

It will be the responsibility of the ILS to ensure the procedures for distribution of government- 
developed software are followed, all applicable criteria are met, approvals obtained and reports 
generated prior to release of any code. The Project Manager will interact closely with Program 
Management during the approval cycle. Following approval, documentation will be assembled and 
software loaded on an appropriate distribution medium (generally cartridge tape). It may be 
necessary for ILS staff to request the assistance of software development staff in the generation of 
distribution tapes. 


4.7 Modifications 

As ILS activities gain momentum there will be an increasing number of opportunities to enhance, 
correct, adapt or otherwise modify FLTA^BI software to suit outside organizations. Although the 
ILS implementation plan requires the ILS to have the capability to make modifications to 
development code, it is inevitable that some burden will be passed to code authors or developers 
most familiar with the code. The degree to which this impedes development progress, or 
conversely, inhibits outside interactions through the ILS, will ultimately be determined by the 
priorities of FLI/YBI and the sense of cooperation among affected staff members. Some initial 
guidelines are proposed that may at least illuminate the potential for conflict and the need to evolve 
some specific policies and procedures. 
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1) Clear statement of current mission from FLI/YBI anc j Program Management: Development 
and support staff must understand the primary purpose of any development effort at any given 
point in time, since most long term efforts are dynamic in this regard. In the 6 years of 
FLI/YBI development, the "mission" has included basic research, research and development, 
fund raising, public relations/promotion, production for end users, and perhaps may others. 

2) Intermediate Change Process: FLI/YBI development phases are planned and implemented on 
the basis of yearly offsite meetings immediately following the completion of a development 
phase and demonstrations. Once development begins, there are no formal mechanisms or 
provisions for departures from the established plan. While this approach is most efficient in a 
close environment, it will be difficult to be responsive to outside organizations under these 
circumstances. It is recommended that some formal means of intermediate design review and 
status planning be perfomed to accommodate ILS activities. The impact on development staff 
should be minimized, but it is important that there is an appropriate level of technical 
representation. 

3) Closed Loop Paper Trail: One important tangible product of ILS activities are reports and 
recommendations submitted to management. To ensure some priority and emphasis is placed 
on these documents, a closed loop method of routing should be implemented whereby products 
from the ILS eventually are returned to the ILS staff with comments from reviewers. 

Comments may include simple acknowledgement of receipt, technical feasibility assessment, 
schedule impact, budget impact, resource impact, priority and any other factors deemed 
appropriate. 


4.8 Other Issues 

4.8.1 Source Code 

A decision was made during the early phases of the A 3 I Program to prohibit incorporation of 
any software in the prototype MIDAS which did not include source code. This policy has 
proven to be critical to the successful integration of MIDAS components, and will continue to 
apply to future developments. The policy has significance to the ILS since it is expected that 
a variety of cooperative agreements will be negotiated whereby code is to be exchanged. The 
software received by FLI/YBI must include source if it is to be considered for incorporation 
in MIDAS. 

4.8.2 Proprietary Software 

The A 3 I Program and others likely to emerge as part of Code FLI/YBI's future activities are 
portions of NASA's overall policy to conduct its activities to contribute to the preservation of 
the role of the United States as leader in aeronautical and space sciences and their 
applications. An essential element of this policy is the ability to transfer new technology 
outside the Agency in an efficient and timely manner. Although the A 3 I Program's early 
objectives were to develop a proof-of-concept prototype in the most expeditious, economical 
manner (i.e. using commercial off-the-shelf software in some instances), later phases have 
seen an increased emphasis on transfer of technology. One obstacle the A 3 ! Program has 
encountered to achieving this element is commercially licensed, proprietary software 
embedded in certain MIDAS component . Consequently, it is recommended that ILS staff 
carefully evaluate the implications of inc< porating proprietary software in MIDAS that may 
subsequently restrict the availability of Mi DAS components. 
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5.0 STAFFING 


5.1 Approach 

The ILS staffing approach was to first identify a relatively comprehensive set of skills and 
responsibilities for the overall ILS. The next step was to outline a phased plan, with suitable skills 
and responsibilities at each stage of staffing. The final step was to develop position descriptions in 
a generic format compatible with NASA APM 48 (REV. OCT 88), Vacancy Announcement, or 
other typical job description formats. The position descriptions appear in Appendix E. 


5.2 Skills & Responsibilities 

The following is a collection of grouped skills and responsibilities identified for a particular 
"requirement" which may be combined to form ILS staff position descriptions. Some attempt has 
been made to prioritize those requirements that were identified, although it is recognized that these 
priorities are subject to change due to management emphasis, economic outlook, research 
objectives and other factors. Highest priority skills are listed first. Desired characteristics are 
provided as additional criteria which may be used to supplement an evaluation of candidate 
knowledge and skills, but are not considered disqualifying requirements if not satisfied. 


Requirement: Liaison 

Knowledge/Skills: 

Human Factors/Human Performance 
Professional Level Publications 
Public Speaking 
Responsibilities: 

Understand & Promote MIDAS Concept 
Understand Functional Limitations and Weaknesses 
Author and Present Technical Papers 
Emphasize Problem Solving Capabilities Available Today 
Identify & Cultivate Candidates for MIDAS Technology 
Supporting Planning Activities 
Characteristics: 

Persuasive 
Team Oriented 

Views Consistent w/Program Office 

Enthusiastic 

Positive Attitude 


Requirement: Designer 

Knowledge/Skills: 

Prior Man-Machine System Design Experience 
Understanding of Typical Design Problems 
Contacts in Government & Industry 
Responsibilities: 

Maintain Technical Liaison w/Outside 
Study Technology of Like Efforts 
Disseminate New Data to Development Staff 
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Report as Necessary 

Generate & Document Technical Recommendations 
Characteristics: 

Bright & Quick Learner 
Self Starter 


Requirement: Facilities Coordination 
Knowledge/Skills: 

Systems Management on Unix & Symbolics Workstations 
Configuration Management Procedures 
Documentation Standards 
Familiarity w/Software QA 
Responsibilities: 

Documentation Maintenance (User & Programmer) 
Software Submissions to COSMIC 
Guest Logistics (badging, orientation, setup, etc.) 
Distribution of Documentation, Reprints, Code, etc. 
Document Usability/User Interface Feedback 
Surveys 

Summary Reports & Functional Recommendations 
Characteristics: 

Junior Level 


Requirement: Software Engineering 
Knowledge/Skills: 

C and LISP Programming Languages 
Systems Integration 
Responsibilities: 

MIDAS Implementation Details 
Technical Recommendation Priority Scheme 
Assist Visiting Staff w/MIDAS Mods as Needed 
Characteristics: 

Ability to Work w/Others 


Requirement: Management 

Knowledge/Skills: 

Technical Staff Management 
Research Environments 
Technology Transfer Requirements 
Responsibilities: 

Contracts/Agreements 
Demonstrations 
Interact with Program Office 
Program Representative as Required 
Liaison w/Technology Utilization Office & NASA/HQ 
Characteristics: 

Leadership 

Initiative 
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Team Oriented 


While it may be argued that each of the above requirements represents a staff position, the practical 
limitations necessitate staffing strategies which optimize the use of manpower by combining, 
distributing and in some cases eliminating lower priority skills or responsibilities. Secondly, a 
phased approached to staffing is anticipated, beginning with a single senior-level position and 
peaking at a level of 3-4 individuals. Three position descriptions, 1) ELS Manager, 2) Technical 
Lead and 3) Technical Support are provided (Appendix E) under the assumption that the ILS 
Manager position will be filled initially, followed by the Technical Lead and lastly the Technical 
Support position. Figure 6 is a proposed phasing plan. 

There will be some overlap in the position descriptions due to the phased approach. Initial ILS 
staff will likely perform most of the duties of the Section, probably at a reduced level. As staff are 
added, responsibilities may be distributed optimally and a greater number of duties performed at a 
higher level of completeness, efficiency and effectiveness. 

In the event a phased approach is not necessary and several staff members may be assigned to the 
ILS at the same point in time, redundant duties and responsibilities across the position descriptions 
may be removed and perhaps replaced with other duties from the requirements listing above. 
Position descriptions for an alternate staffing approach are provided where the ILS Manager is 
hired first, followed by two additional staff members simultaneously at a later date. 


Position 1990 1991 



6.0 FACILITIES 

6.1 Rationale 

The move to more actively foster inter-Govemment and Government-industry cooperative 
development has precipitated a requirement to provide government facilities at Ames to visiting 
staff from participating organizations. Ames is the most appropriate location to conduct joint 
activities because the staff expertise and equipment are available at Ames, while some of the 
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products developed by FLI/YBI contain components that are proprietary or have restricted release 
which presently limits distribution outside Ames. Proposed facilities include furnished office 
space, computer equipment space with properly conditioned power and cooling, and access to 
existing FLI computer equipment. 

Previous cooperative arrangements have been primarily staff oriented, whereby representatives 
from Boeing, Sikorsky, Lockheed, etc. work directly with in-house software engineering staff at 
Ames for periods ranging from 2 weeks to several months. FLI/YBI software engineers typically 
instruct visiting staff on procedural issue in using the software and technical details of its 
implementation so that these developers may make any necessary modifications to suit their 
specific problems. 

Other relationships may involve temporary or permanent integration of additional hardware into the 
prototype HF/CAE workstation suite from cooperating organizations in exchange for access to the 
workstation, software support and training. 


6.2 Proposed Office Facilities 

Upon completion of the new Human Performance Research Laboratory and occupation in March, 
1990, there will be a reorganization and allocation of office space to those branches which remain 
in building N239, namely the Crew Research and Space Human Factors Branch and the 
Computation Human Engineering Research Office. The proposed allocation of space for FLI/YBI 
is depicted in the shaded areas of Figure 7, representing about 30% of available space. The 
remaining space is allocated to the Crew Research and Space Human Factors Branch. Given this 
configuration, the present plan calls for the following assignments: 


Room 174 

Lab Computer Equipment 

Room 173 

PSTA Manager + 2 staff 

Room 172 

Lab 

Room 171 

Branch Secretary 

Room 17 OB 

ILS Visiting Staff Offices 

Room 170 A 

4 Software Engineers 

Room 169 

Branch Chief 

Room 167 

Software Support Task Manager 

Room 165 

Principal Scientist 

Room 163 

2 Software Development Group Leaders 

Room 101 

A 3 I Deputy & ILS Manager 

Room 103 

2 Software Engineers 

Room 105 

2 Software Engineers 
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The current allocation of space is already insufficient, since the present A 3 I Program staff 
complement alone fills the available space with no room for 5 currently unfilled staff positions (2 
ILS, 3 programmer). Furthermore, it is highly likely that the Computational Human Engineering 
Research Office will grow in the near future to include other projects in addition to A^I. Some 
resolution is necessary to avoid the expense and inefficiency of placing contract staff in trailers. 
The above allocation of space appears to be deficient by approximately 4-7 "desks" in meeting the 
current and near future needs of FLI/YBI. 


6.3 Requirements 

The anticipated facilities requirements are outlined below. 

Office Space. It is expected that from 1 to 3 individuals from each organization will work at Ames, 
while 1 or 2 organizations may be represented at any time. Since industry tends to be 
proprietary in the presence of perceived competition, it is important to provide at least two 
relatively isolated (enclosed area with doors) office areas so that developers may work 
uninhibited when there are two industry organizations present simultaneously. Two 10' by 12' 
areas would likely be sufficient to accommodate the maximum number of persons expected (3) 
per area. Area lighting should be fluorescent. Task lighting may be included for use near the 
furnished areas. 

Furniture. The requirements for each 10' by 12' area include 2 desks, 3 chairs, a 2-drawer 
(minimum) file cabinet, 2 bookcases and a table. 

Conditioned Power. Power supplied to theses areas should be conditioned in the event that 
participating organizations bring additional computer equipment to the site, or equipment is 
moved to these areas for use by visiting staff. 

Equipment. Ideally, 1 Silicon Graphics Personal IRIS, I Symbolics 3620 or Maclvory and two 
ASCII terminals would be available as pool resources beyond the core equipment currently 
utilized by FLI development staff. This equipment would be dedicated to visiting staff as the 
first priority, and other FLI staff on an "as available" basis. 

Access to Existing Facilities. Both electronic and physical access should be provided to allow free 
communication between visiting staff and FLI staff. It should be convenient to move between 
the office space and the FLI development laboratory. Cabling between existing equipment and 
future installations for use by visiting staff should be provided via raised floor or concealed 
cable runs. 

Safety. Smoke detectors tied to the master building system should be provided. A minimum of 
two egress routes from each office area should be available in the event of a fire or other 
hazard. 
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6.4 Projected Costs 


Structural Modifications (NASA SR) 

Lighting (NASA SR) 

Furniture (NASA/Army PR) 

Personal IRIS Graphics Computer (NASA PR) 

Symbolics 3620 (NASA PR) 

2-ASCII Terminals (Task ODC) 

TOTAL 

7.0 FUTURE DIRECTIONS 

7.1 Research 

Code FLI/YBI is a research office and as such will continue to facilitate and perform computational 
human factors research activities. Prior to the completion of A 3 I as a research project it is 
anticipated that certain aspects of A 3 I will be formally designated "research" in nature and detached 
from production requirements and the pull of the user community. The ILS will remain cognizant 
of these eminent divisions and serve to inform the user community of the status of ongoing 
research developments. ILS staff will make clear the distinction between research and pilot or 
production developments, and identify each major MIDAS component as belonging to one of these 
classifications. 


$ 5,000.00 

$ 2 , 000.00 

$ 10,000.00 

$ 35,000.00 

$ 30,000.00 

$ 2,000.00 

$ 84,000.00 


7.2 Production 

The A 3 I Program is rapidly reaching matumy as an exploratory research program, and will likely 
begin transitioning to development and production phases in the near future. This transition 
requires skills and procedures that are often in conflict with the goals and objectives of fundamental 
research activities. Consequently, provisions must be made for a smooth transition which 
minimizes resource and organizational conflict. 

More significantly, it is important to establish clear boundaries between research and production 
elements to facilitate the acquisition of funding from the widest possible range of government and 
industry sources. 


7.3 Commercialization 


Many of the products and services developed by FLI/YBI staff and support personnel are suitable 
for commercialization. Several mechanisms exist that enable the government to benefit from 
commercialization of products developed with government funding. Benefits include professional 
recognition, royalties, patent rights, copyrights and other negotiable advantages. ILS staff are 
positioned to anticipate commercialization of FLI/YBI products based on outside demand, and may 
assist with laying the foundation for implementing commercialization or joint endeavor agreements. 
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7.4 Funding 

Trends in FLI/YBI funding over the life of the A 3 I Program have been unfavorable due to sizable 
cuts in defense spending for R&D. As a result, innovative and creative approaches to 
accomplishing necessary development have been increasingly entertained. These approaches have 
primarily centered around cooperative or collaborative agreements where code is provided in 
exchange for ft; ding from another government agency. An optimistic viewpoint would contend 
that serious interest from industry in mature MIDAS products will be accompanied by funding. 
While additional funding is certainly desirable, some caution is necessary for reasons of 
competitive advantage previously mentioned. The ILS will play a major role in identifying and 
ascertaining the suitability of any organization outside the government for supplying FLI/YBI with 
funding. 


8.0 CONCERNS 

8.1 Startup & Staffing 

The crucial step in building an effective ILS will be the selection and orientation of the Project 
Manager. The qualifications of this individual have been outlined, but the criticality of this position 
has not been adequately addressed. The importance of this initial position (it is assumed that the 
manager position will be filled first) is largely dictated by the fact that it is likely the Project 
Manager will be performing the duties of the entire ILS for an indefinite period of time. The period 
of time may simply be contingent on the success or failure of the Manager to generate sufficient 
tangible interest outside FLI/YBI in the form of cooperative agreements, requests for software or 
funding. Overall effectiveness is also determined by the ability of the Manager to interact with all 
factions of the Program from Management and Chief Scientists to software engineers. In short, 
the ILS Manager must be successful and team oriented if the ILS concept is to gain acceptance and 
momentum. 


8.2 Facilities 

The proposed N239 office facilities are barely adequate for even the existing staff level, which is 
presently under complement by 5 unfilled positions. Little or no space has been provided for 
expansion, which is inevitable given the available positions, the mission of Code FLI/YBI 
(research) and the apparent direction of many aspects of A 3 I (production). 


8.3 Organizational Conflict 

FLI/YBI and support staff represent a unique and sometimes complex mixture of NASA, Army, 
grantee, contractor and subcontractor staff. The A 3 I Program has enjoyed an unprecedented 
degree of success managing this diverse collection of capabilities because all participants could 
generally be focused on a single goal (completion of phase of development) with minimal 
competing objectives. As FLI/YBI grows and expands into research domains, and as staff are 
added who may be matrixed across several responsibilities, the task of motivating and managing 
will become significantly more difficult. The ILS may find itself wedged in the middle ot this 
complexity because toplevel direction and approval is provided at the Office level, but 
implementation of ILS objectives is heavily dependent on the degree ol cooperation between ILS 
staff and both support and development staff. There is no simple organizational solution to this 
complexity, however ILS staff members who must function effectively in this environment should 
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be selected with some sensitivity to their communications skills and the ability to work well with a 
variety of professionals. 

A more radical proposal than careful staff selections would be to place the ILS as a support 
function within the FLI/YBI Office in the same manner as PSTA. While this would not guarantee 
success, it would increase the visibility of ILS and provide additional authority. However, since 
the ILS is a new and evolving area, it is recommended that the current structure be implemented 
initially until the purpose and priority of ILS activities become more clearly defined. 


8.4 Technical Issues 

Early A 3 I development phases emphasized incremental software development, rapid prototyping, 
object-oriented programming techniques and language/operating system standardization as the 
preferred tools and techniques to be employed in all software development. While it was 
acknowledged indirectly that some of these techniques facilitate portability, there has been a 
reduced emphasis on this issue in recent phases. The ILS is in a position to heighten sensitivity to 
software portability by virtue of its influence on reliability, quality assurance and configuration 
management policy. These policies and procedures should be developed with an appropriate level 
of consideration to the portability issue. 
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Appendix A. A 3 I Software Modules and Configuration Data 
(including Distribution Status) 


Jack 


Interactive application program to display and manipulate articulated geometric figures. Used 
by A^I to analyze human reach and fit, comfort, etc. in advanced helicopter cockpits. 
Integrated by A^I staff with 3D environment construction tools (CDE/VIEWS). 


Name 

WBS/CI Number 
Language(s) 

Hardware Platform(s) 
Minimum Configuration 


A^I OS Version 


Latest OS Version 


Baseline Version & Date 
OS Compatibility 


Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 


Configuration Management 
Outside Interest 


Jack 

C 

All Silicon Graphics 
?? MB RAM 
?? MB Mass Storage 
?? Bit Planes 
19 in. Monitor 
3000 Series: 3.6 
4D Series: 3. ID 
GTX: 3. ID 
3000 Series: 3.6 
4D Series: 3.2.1 
GTX: 3.2.1 

Version 3.10, February, 1989 
3000 Series: 3.5 - 3.6 binary compat. 

4D Series: 3. 1C - 3.2 binary compat. 

3000->4D: Recompile required 
Version 3.10, February, 1989 
4.0 

September, 1989 

Jack User's Guide, Version 2.0, September 12, 1988 & 
2.1, November 11, 1988, Computer Graphics Research 
Laboratory, Dept, of Computer and Information Sciences, 
University of Pennsylvania. 

McDonnell Douglas Helicopter (Longbow) 

Patuxent River Naval Air Station 
Boeing Commercial Airplanes 
Douglas Aircraft Company 
TACOM 


Distribution Status: UPenn has given permission for release of binaries only, provided 
UPenn is notified of who receives the code. UPenn must be contacted directly regarding 
release of source code. 


Acquisition Options: 

1) Request code from COSMIC after it is submitted by A^I and becomes available. 
Binaries only will be submitted, provided COSMIC has a mechanism for tracking 
and reporting who receives the code. Cost is unknown at this time. 

2) Executable code may be directly released by A^I if a cooperative/contractual 
agreement exists between the A^I Program and the recipient. Acknowledgements 
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are required, and approvals must be obtained at NASA/Ames and NASA/HQ prior 
to release. Recipient may not subsequently distribute software received under this 
provision. 

3) UPenn may be contacted directly (Dr. Norman Badler). 


Mission Specification/Task Decomposition 

Initial implementation was Mission Decomposition Methodology, an object-oriented 
framework for creating discrete time simulations of hierarchical human-machine task 
interactions. The Mission Decomposition Methodology was separated into mission, pilot and 
vehicle components for independent development. 


Name 

WBS/CI Number 
Language(s) 

Hardware Platform(s) 
Minimum Configuration 

A^I OS Version 
Latest OS Version 
OS Compatibility 
Baseline Version & Date 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 


Configuration Management 
Outside Interest 


Mission Specification/Task Decomposition 

Symbolics Common LISP 
All Symbolics 
?? MB RAM 
?? MB Mass Storage 
Genera 7.2 
Genera 7.2 

Genera 7.0->Genera 7.2 
Phase III, December, 1988 


Phase HI Symbolic Modeling SDDD, December, 1988, 
Jerry Murray, Sterling Software. 

BBN Report No. 6431, December, 1986 


Boeing Commercial Airplanes 


Distribution Status: BBN has granted approval for the release of the software, provided 
appropriate acknowledgements to both BBN and NASA are given. This software is 
classified as "pilot" code and may be submitted to NASA COSMIC. 

Acquisition Options: 

1) Request code from COSMIC after it is submitted by A 3 I and becomes available. 
Source will be available (LISP). Cost is unknown at this time. 

2) Code may be directly released by A 3 I if a cooperative/contractual agreement exists 
between the A^I Program and the recipient. Acknowledgements are required, and 
approvals must be obtained at NASA/Ames and NASA/HQ prior to release. 
Recipient may not subsequently distribute software received under this provision. 


Symbolic Pilot Model 

Symbolic pilot model initially existed as an integrated component of the task decomposition 
methodology. Subsequently separated and enhanced in by in-house development staff to 
allow independent development and exploration of computational human performance 
models. The current VACP resource model is being extended to include context sensitivity 
and multiple resource theory. A constraint-based, dynamic, adaptive, opportunistic 
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scheduler is also being designed. Symbolic pilot model is separate and distinct from 
"analytical" pilot models such as Jack, and attempts to model more cognitive and qualitative 
aspects of human behavior and performance. 


Name 

WBS/CI Number 
Language(s) 

Applications 

Hardware Platform(s) 
Minimum Configuration 

A^I OS Version 
Latest OS Version 
OS Compatibility 
Baseline Version & Date 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 


Configuration Management 
Outside Interest 


SymbolicPilot Model 

Symbolics Common LISP 

GEST 3.0 (Georgia Tech Research Institute) 

SOAR V5 (CMU) 

All Symbolics 
?? MB RAM 
?? MB Mass Storage 
Genera 7.2 
Genera 7.2 

Genera 7.0->Genera 7.2 
Phase III, December, 1988 


Part of Phase III Symbolic Modeling SDDD, December, 
1988, Jerry Murray, Sterling Software. 

BBN Report No. 6431, December, 1986 


Distribution Status: This software is classified as development, and is not appropriate for 
submission to COSMIC. 


Acquisition Options: 

1) Code may be directly released by A^I if a cooperative/contractual agreement exists 
between the A 3 I Program and the recipient. Acknowledgements are required, and 
approvals must be obtained at NASA/Ames and NASA/HQ prior to release. 
Recipient may not subsequently distribute software received under this provision. 

2) Portions of the code which do not exceed $ 50,000 in development cost may be 
directly released by A^I, with acknowledgments. 


Training Assessment Module 

The Training Assessment Module was designed to 1) give equipment designers early 
feedback about the training implications of design decisions, and 2) provide training program 
designers with training requirement prediction information that may be used to develop 
appropriate instructional approaches. Software was developed entirely by A^I software 
development staff (Sterling Software), although the methodology was based on Logicon, 
Incorporated's Training Analysis Support Computer System (TASCS). 


Name 

WBS/CI Number 

Language(s) 

Applications 

Hardware Platform(s) 
Minimum Configuration 


Training Assessment Module 
None 

Symbolics Common LISP (I/O functions) 

Inference Corp. Automated Reasoning Tool (ART), 
Version 3.2 
All Symbolics 
?? MB RAM 
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?? MB Mass Storage 
Genera 7.2 
Genera 7.2 

Genera 7.0->Genera 7.2 
ART V?->ART V3.2 
Phase III, December, 1988 


Phase III Training Assessment SDDD, December, 

1988, Carolyn Banda, Sterling Software. 

None 

AAA V Program Office 
NTSC (AAAV Program Office) 

NASA/Marshall Space Center 
Distribution Status: Code is considered pilot or production and is appropriate for submission 
to to NASA COSMIC. 

Acquisition Options: 

1) ART is required. Request code from COSMIC after it is submitted by A^I and 
becomes available. Source will be available (LISP). Cost is unknown at this time. 

2) ART is required. Code may be directly released by A^I if a cooperative/contractual 
agreement exists between the A^I Program and the recipient. Acknowledgements 
are required, and approvals must be obtained at NASA/Ames and NASA/HQ prior 
to release. Recipient may not subsequently distribute software received under this 
provision. 


A 3 I OS Version 
Latest OS Version 
OS Compatibility 
Application Compatibility 
Baseline Version & Date 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 

Configuration Management 
Outside Interest 


Cockpit Display Editor and Views 

A tool designed to construct and animate 3D graphical representations of helicopter cockpits 
and simulated environments for human factors analysis. The application is an A-^I-modified 
version of commercial software (MultiGen) designed for visual system data base modeling. 


Name 

WBS/CI Number 

Language(s) 

Application 


Hardware Platform(s) 
Minimum Configuration 


A^I OS Version 


Latest OS Version 


OS Compatibility 


Cockpit Display Editor and Views 
C 

Software Systems' MultiGen 
Kernel Version 3.0, 8/12/88 
Might DBL Version 4.0, 7/88 
All Silicon Graphics 
8 MB RAM 

100 MB Mass Storage for development 

10 MB Mass Storage for execute only 

24 Bit Planes 

19 in. Monitor 

3000 Series: 3.6 

4D Series: 3. ID 

GTX: 3. ID 

3000 Series: 3.6 

4D Series: 3.2.1 

GTX: 3. ID 

3000 Series: 3.5 - 3.6 binary compat. 
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4D Series: 3. 1C - 3.2 binary compat. 
3000- >4D: Recompile required 
No compat. w/newer versions 
Phase III, December, 1988 


MultiGen Programmer's and User's Documentation, 
November, 1988, Software Systems. 

Phase III Cockpit Design Editor SDDD, December, 1988, 
Teh-Ming Hsieh, Sterling Software. 

Phase III Views SDDD, December, 1988, Andrew Lui, 
Sterling Software. 

MultiGen: RCS 
CD E/Views: None 
Patuxent River Naval Air Station 
McDonnell Douglas Helicopter 
Lockheed Missiles and Space 
NTSC (AAAV Program Office) 

FAA Aviation Safety and Automation Program 
Trimble Navigation Systems 
Douglas Aircraft Company 
TACOM 

Distribution Status: CDE and Views may not be distributed directly by NASA due to the 
proprietary restrictions of the basis code, MultiGen. 

Acquisition Options: 

1) Executable licenses are available from Coryphaeus Software, Monte Sereno, CA 
(408-395-4537) for $ 30,000. Price includes software on cartridge tape, 
installation, user training, documentation and limited support. Acknowledgements 
are required, and approvals must be obtained at NASA/Ames and NASA/HQ prior 
to release of Government-developed code. Source is available, fees negotiable. 

2) Executable licenses are available from Software Systems, San Jose, CA (408-995- 
0689) for $ 25,000 without documentation or support. A 3 I is responsible for 
necessary approvals, distribution and support. 

3) Portions of the code which do not exceed $ 50,000 in development cost may be 

directly released by A 3 !, with acknowledgments. 


Application Compatibility 
Baseline Version & Date 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 


Configuration Management 
Outside Interest 


Communications 


Application software used to transfer math model output data to the graphic display 
application soft re in a scaled time simulation. Software developed entirely by A 3 I software 
development stai f. 


Name 

WBS/CI Number 
Language(s) 

Hardware Platform(s) 

Minimum Configuration 


Communications 
C, LISP 

All Silicon Graphics 
All Symbolics 
?? MB RAM 
?? MB Mass Storage 
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A^I OS Version 


Latest OS Version 


OS Compatibility 


Baseline Version & Date 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 

Configuration Management 
Outside Interest 


3000 Series: 3.6 

4D Series: 3. ID 

GTX: 3. ID 

Symbolics Genera 7.2 

3000 Series: 3.6 

4D Series: 3.2.1 

GTX: 3.2.1 

Symbolics Genera 7.2 

3000 Series: 3.5 - 3.6 binary compat. 

4D Series: 3. 1C - 3,2 binary compat. 

3000- >4D: Recompile required 

Symbolics: Genera 7.0->Genera 7.2 

Phase III, December, 1988 


Phase III Communications SDDD, December, 1988, Alex 
Chiu, Sterling Software. 

None 

Lockheed Missile and Space 


Distribution Status: Code does not meet the criteria for submission to NASA COSMIC, but 
may be released directly by A^I. Source (C and LISP) is available. 

Acquisition Options: 

1) Request code from A^I Program Office. Acknowledgements are required. 


Aero/Guidance 

Existing application software developed for man-in-the loop simulation which was adapted 
by A^I to compute linear, uncoupled, 6 degree-of-freedom helicopter dynamics. The 
algorithms were adapted under subcontract, while implementation, integration and 
modifications were performed in-house. 


Aero/Guidance 


Name 

WBS/CI Number 
Language(s) 

Hardware Platform(s) 
Minimum Configuration 

A^I OS Version 


Latest OS Version 


OS Compatibility 


Baseline Version & Date 
Major Release Version & Date 


C, FORTRAN IV 
All Silicon Graphics 
minimal RAM 
minimal Mass Storage 
3000 Series: 3.6 
4D Series: 3. ID 
GTX: 3. ID 
3000 Series: 3.6 
4D Series: 3.2.1 
GTX: 3.2.1 

3000 Series: 3.5 - 3.6 binary compat. 
4D Series: 3. 1C - 3.2 binary compat. 
3000- >4D: Recompile required 
Phase III, December, 1988 


Development Software Version 
Last Minor Update 

Documentation Phase III Aero/Guidance SDDD, December, 1988, Alex 

Chiu, Sterling Software. 

Analytical Mechanics Associates Contractor Report 

Configuration Management 
Outside Interest 

Distribution Status: Code is considered pilot or production and is appropriate for submission 
to NASA COSMIC. 

Acquisition Options: 

1) Request code from COSMIC after it is submitted by A 3 I and becomes available. 
Source (FORTRAN) will be available. Cost is unknown at this time. 

2) Code may be directly released by A^I if a cooperative/contractual agreement exists 
between the A 3 I Program and the recipient. Acknowledgements are required, and 
approvals must be obtained at NASA/Ames and NASA/HQ prior to release. 
Recipient may not subsequently distribute software received under this provision. 

3) Contact NASA/Ames Software Lending Library manager (Sterling Software) for 
policy regarding distribution of original TMAN program. 


Volumetric Field-of-View Vision Model 

3D volumetric projection of the pilot's field-of-view developed under NASA Grant to the 
New York Association for the Blind. 


Name 

WBS/CI Number 
Language(s) 
Applications 
Hardware Platform(s) 
Minimum Configuration 

A^I OS Version 


Latest OS Version 


OS Compatibility 


Application Compatibility 
Baseline Version & Date 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 
Configuration Management 
Outside Interest 


Volumetric Field-of-View Vision Model 

None 

C 

Jack Version 3.10 (display environment) 

All Silicon Graphics 

?? MB RAM 

?? MB Mass Storage 

3000 Series: 3.6 

4D Series: 3. ID 

GTX: 3. ID 

3000 Series: 3.6 

4D Series: 3.2.1 

GTX: 3.2.1 

3000 Series: 3.5 - 3.6 binary compat. 

4D Series: 3. 1C - 3.2 binary compat. 
3000->4D: Recompile required 
Jack V3.1->Jack V4.0 


August, 1989 
AFHRL 

Douglas Aircraft Company 
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Distribution Status: Aries Ardidit has granted permission to distribute the volumetric field of 
view software in binary form, with acknowledgements. Code is considered pilot or 
production and is appropriate for submission to to NASA COSMIC. 

Acquisition Options: 

1) Request code from COSMIC after it is submitted by A 3 I and becomes available. 
Binaries only will be submitted, provided COSMIC has a mechanism for tracking 
and reporting who receives the code. Cost is unknown at this time. 

2) Code may be directly released by A^I if a cooperative/contractual agreement exists 
between the A^I Program and the recipient. Acknowledgements are required, and 
approvals must be obtained at NASA/Ames and NASA/HQ prior to release. 
Recipient may not subsequently distribute software received under this provision. 

3) Contact the New York Association for the Blind directly. 


Visibility Vision Model 

Developed under contract with David Samoff Research Center as part of ongoing 
development at Samoff. Analytical model to predict legibility of specific information under 
particular environmental conditions such as lighting, sun angle, equipment location and 
emissive characteristics. The application is image-based (vs. polygon/geometry-based) and 
requires photographic quality image input. It is also projected to execute on SUN 
Microsystems hardware. 

Visibility Vision Model 
C 

Sun Microsystems 
?? MB RAM 
?? MB Mass Storage 
TBD 
TBD 


AFHRL 

Douglas Aircraft Company 

Distribution Status: It is expected that Samoff Labs will give permission for release of 
binaries only under the same conditions as UPenn and N.Y. Association for the Blind 
software. A formal position has not been issued at this time. 

Acquisition Options: 

1) Expected to be the same as New York Association for the Blind, but currently 
unverified 


Name 

WBS/CI Number 
Language(s) 

Hardware Platform(s) 
Minimum Configuration 

A^I OS Version 
Latest OS Version 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 
Configuration Management 
Outside Interest 


Visual Modeler 
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A prototype application designed to allow graphical creation of math models that was 
developed under subcontract to Expert EASE Systems. Uses data flow simulation methods. 
Not currently integrated with MIDAS. 


Name 

WBS/CI Number 
Language(s) 

Hardware Platform(s) 
Minimum Configuration 

A^I OS Version 
Latest OS Version 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 
Configuration Management 
Outside Interest 


Visual Modeler 

Symbolics Common LISP 

All Symbolics 

?? MB RAM 

?? MB Mass Storage 

Genera 7.0 

Genera 7.2 

Phase II, July, 1987 


Expert EASE Contractor Report 


Icon Editor 

Application to allow non -programmers to create and connect various 2D display types to 
simulation variables for display (tap probes) or to interact with the displays to alter values of 
simulation variables (tap sets). Extracted from STEAMER application developed by BBN 
for Navy Personnel Research and Development Center for interactive training devices. Not 
used in Phase III. 


Name 

WBS/CI Number 
Language(s) 

Hardware Platform(s) 
Minimum Configuration 


A^I OS Version 
Latest OS Version 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 
Configuration Management 
Outside Interest 


Icon Editor 

Symbolics LISP 

All Symbolics 

?? MB RAM 

?? MB Mass Storage 

Color Monitor (will work in B&W) 

Genera 7.0 

Genera 7.2 

Phase II, July, 1987 


Phase II SDDD 


Modeler 

Application used in Phase II to control overall execution of the A-^I simulation and provide an 
integrated environment of constructing simulations. Based initially on STEAMER executive 
due to ability to handle variable resolution and rate math models. Not used in Phase III. 

Name Icon Editor 

WBS/CI Number 
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Language(s) 

Hardware Platform(s) 
Minimum Configuration 

A^I OS Version 
Latest OS Version 
Major Release Version & Date 
Development Software Version 
Last Minor Update 
Documentation 
Configuration Management 
Outside Interest 


Symbolics LISP 
All Symbolics 
?? MB RAM 
?? MB Mass Storage 
Genera 7.0 
Genera 7.2 
Phase II, July, 1987 


Phase II SDDD 
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Appendix B. Sample Memorandum of Agreement 


MEMORANDUM OF AGREEMENT 

Between Army-NASA Aircrew/Aircraft Integration Program Office 
and the NASA/Ames Information Sciences Office 


This agreement between the Army-NASA Aircrew/Aircraft Integration Program Office within the 
Aerospace Human Factors Research Division (FL) and the Information Sciences Office (ISO) at 
NASA/Ames Research Center defines the support ISO will provide the A 3 ! Program. 

The A 3 I Program is a joint Army-NASA research and development undertaking requiring expertise 
from a variety of disciplines such as engineering, computer science, artificial intelligence, human 
performance modeling, cognitive sciences, training, operations, reliability and quality assurance, 
safety, and manufacturing. Many centers of excellence exist throughout the U.S. that specialize in one 
or a number of these areas, for example MIT, Stanford and Carnegie-Mellon Universities in select 
areas of artificial intelligence. 

The approach adopted by the A 3 I Program for achieving the specified goals, involves coordinating an 
effort which utilizes as its foundation, the findings of various centers of excellence. The Information 
Sciences Office at NASA/Ames is considered one such center. 

It is agreed that the following tasks will be performed by ISO for the A 3 I Program: 

(1) Develop a (brief) functional specification describing the 
training issues and proposed implementations within the 
overall A 3 I designers workstation. 

(2) Develop an expert system consistent with other A 3 I hardware 
and software structures which implements the concepts 
described in (1). 

(3) Provide support for integration of the training expert 
system component of the overall workstation structure. 

(4) Support scheduled demonstrations as required by the Program 
Office. 

(5) Provide progress reports to the Program Office as needed. 

(6) Establish and maintain contact with other Program 
participants that are providing relevant expertise 

or deliverables. 


The preliminary schedule indicates required completion dates for 
specified tasks. 
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TASK PROGRAM YEAR 

86 87 88 89 90 91 

Functional X — X 

Specification 

Expert System X— — X 

Development 

Demonstration X XXX 

Integration X X 

The A 3 I Program will provide funds to support the ISO task elements. These funds shall be consistent 
with overall program resources and will be negotiated anually dependent on progress and needs. 

The A^I Program point of contact will be E. J. Hartzell (415-694- 5743, MS 239-21 Room 1 19). 


CONCURRENCE 

date 


C. Thomas Snyder - Director, Aerospace Systems 


CONCURRENCE 

date 


David C. Nagel - Chief, Aerospace Human Factors Research Div. 


CONCURRENCE 

date 


Victor L. Peterson - Director, Astronautics 


CONCURRENCE 

date 


Henry Lum, Jr. - Chief, Information Sciences Office 
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Appendix C. Sample Interagency Agreement 


A MEMORANDUM OF AGREEMENT BETWEEN THE ARMY AVIATION RESEARCH AND 
TECHNOLOGY ACTIVITY (AVSCOM) AND THE AMES RESEARCH CENTER(NASA) 


FOR THE JOINT ARMY/NASA AIRCREW AIRCRAFT INTEGRATION PROGRAM 


The Aviation Research and Technology Activity (ARTA-AVSCOM) and the Ames Research 
Center (NASA) are presently engaged in joint research activities aimed at improving the working 
environment of the modem helicopter pilot and of the ability of this man-machine system to perform 
the missions assigned. These activities reflect the recognition that a crew- 

performance/workload/training problem exists in today's civil and tactical military helicopters that can 
contribute to mission failure or loss of aircraft or crew. There is a need to develop predictive 
computational methods to be able to design efficient cockpits and to train aircrews to assure a symbiotic 
relationship between the man and the machine. The objective of both agencies is to develop an 
interactive computer-based design and analysis system that incorporates models for system simulation, 
human behavior and performance models, graphics, expert systems, and other tools for use by 
designers and planners of cockpits and training devices for future advanced technology rotorcraft. 

The focus from the Army's point of view is the single-seat scout/attack rotorcraft with a 
capability to perform its mission at night, in adverse weather, and operating in the nap-of-the- earth 
environment. From the NASA perspective, the focus is the highly automated helicopter with full 
capability for single pilot IMC operation. 

This program is to establish reliable predictive computational methods that will enable: 

1. Engineers to design helicopter controls, and automated systems displays, with assurance 
that the consequent man-machine system will accomplish its mission with satisfactory performance, 
acceptable workload, and reasonable cost. 

2. Users to develop rotorcraft training systems and 

devices that will support the required level of aviator capability at acceptable cost. 

The program will be jointly managed and funded by the Army and the NASA. The particular 
organizations responsible for managing the program are the Aeroflightdynamics Directorate of the 
Aviation Research and Technology Activity (AVSCOM) and the Aerospace Systems Directorate of the 
NASA Ames Research Center, both of which will be active in all elements of the program. The 
Program Office will be located within the Aerospace Human Factors Research Division at Ames and 
will report to the Chief of that Division. It is expected that there will be active participation by the 
Avionics R&D Activity (AVSCOM); the Applied Technology Directorate (ARTA-AVSCOM); the 
Army Research Institute for Behavioral and Social Sciences; the Army Human Engineering Laboratory; 
the Directorate for Training and Doctrine (USAAVNC) in those portions of the program that are 
relevant to the interests and activities of the respective organizations. The NASA Ames Research 
Center's Information Sciences Office will play an important role in the program as will other related 
Center organizations. 

The program is established under the auspices of and pursuant to the terms of the "Agreement 
between the National Aeronautics and Space Administration and the Army Materiel Command for Joint 
Participation in Aeronautical Technology Related to Army Aviation", dated November 12, 1969, and 
"An Agreement between the National Aeronautics and Space Administration and the United States 
Army Materiel Development and Readiness Command for Joint Participation in Aeronautical 
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Technology at the Ames Research Center, Moffett Field, California", revision dated 18 February, 
1983. In accordance with the concepts of operation of these agreements, each agency will provide 
funding, support, and personnel as these resources are available, but generally in accordance with the 
program plan to achieve a major objective within five years. 

The Directors of Aeroflightdynamics, ARTA, and of Aerospace Systems of NASA-Ames, or 
their designated representatives, will establish procedures in a manner responsive to the needs of their 
respective agencies for periodic review of the Army/NASA Aircrew Aircraft Integration Program to 
ensure proper direction of effort and to determine the technical, administrative, fiscal, and personnel 
adequacy of the program. 

The provisions of this agreement are subject to modification or termination of the NASA/Army 
agreement dated November 12, 1969 (NASA NMI 1052.123). 


date 


date 


Director Director 

NASA Ames Research Center Aviation Research and 
Technology Activity 


date 


date 


Director Director 

Aerospace Systems Aeroflightdynamics 
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Appendix D: Sample Technical Exchange Agreement 


TECHNICAL EXCHANGE AGREEMENT 


BETWEEN THE 

ARMY/NASA AIRCREW-AIRCRAFT INTEGRATION PROGRAM OFFICE 

AND 

<ORGANIZATION> 

IN THE AREA OF GRAPHICAL PROTOTYPING TOOLS 

FOR 

COMPUTATIONAL HUMAN ENGINEERING ANALYSIS 


The National Aeronautics and Space Administration, by virtue of the National Aeronautics and 
Space Act of 1958, is directed to conduct its activities so as to contribute to the preservation of the 
role of the United States as a leader in aeronautical and space science and technology, and their 
applications. NASA recognizes that technical exchanges between the Agency and industrial 
organizations will accelerate understanding of the use of graphical prototyping techniques in 
developing computational human engineering principles and methodologies. <Organization> 
recognizes that NASA has developed prototype tools which can enhance the firm's ability to meet 
the aerospace industry's needs for graphical design tools. 

Accordingly, effective when signed by the last signatory to this Agreement, the National 
Aeronautics and Space Administration (hereafter NASA), Washington D.C. 20546 and 
<Organization>, having a principal place of business at <address>, agree as follows: 


ARTICLE I - PURPOSE, SCOPE, AND CONSIDERATION 

1.01 For the purpose of investigating the usage of graphical techniques for prototyping and 
subsequent analysis of man-machine interfaces, NASA and <Organization> agree to 
exchange technical information and to consult on the development of a flexible design 
environment for rapidly prototyping and animating cockpit displays and controls (hereafter 
SUBJECTS). This technology is currently under development within the NASA/Ames 
Computational Human Engineering Branch (Code FLI) as part of the Army/NASA 
Aircrew-Aircraft Integration (A^I) Program. 

1 .02 Both parties shall exert their best efforts and cooperate in good faith to achieve the purpose 
of this Agreement. All work done by either party in conjunction with or related to this 
Agreement is at the sole discretion and expense of that party. There will be no exchange of 
funds under this Agreement, the sole consideration residing in the cost-free exchange of 
information and data on the SUBJECTS. The parties recognize that NASA's ability to 
perform its obligations hereunder is subject to the availability of appropriated funds. 


ARTICLE II - RESPONSIBILITIES 

2.01 <Organization> shall contribute the following to the Agreement, valued at <$ value> 
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i) design, code and test a series of functional enhancements to the set of existing NASA 
prototype tools currently used by the A^I Program for studying the human factors 
implications of helicopter cockpit designs. The enhancements are listed below in order 
of development priority, based on an assessment of needed capabilities at the time of 
this agreement, but do not represent a rigid commitment to generate the identified 
capabilities. The composition and priorities of the list are likely to change over the term 
of this agreement subject to NASA and <Organization> requirements. 

Projected Functional Enhancements to NASA Graphic Prototyping Tools 

1 ) Perspective Display Editor 

2) Improved User Interface 

3) Display/Control Library 

4) Interfaces to SGI "Personal Visualizer" Rendering Package 

5) On-Line Display/Control Design Aiding (heuristic) 

6) HUD Editor 

7) HMD Editor 

8) Raster Fonts on Multi-Function Displays 

9) Extendible Simulation Variable Interface 

ii) collaborate with NASA and NASA contractors on the integration of functional 
enhancements i) above; 

iii) advise NASA on areas where functional capabilities not currently supported by the 
existing set of tools or functional enhancements above is lacking and provide inputs to 
any development which NASA may consider or conduct; 

iv) collaborate with NASA and NASA contractors on the development of interfaces 
between the graphical prototyping tools and both existing and potential analysis tools; 

v) develop complete user documentation for NASA graphical prototyping tools; 

vi) provide demonstrations, temporary evaluation copies of executable code, 
documentation, training and other user support to organizations designated by NASA 
(the A^I Program Office) relating to the graphical prototyping tools. Obtain necessary 
approval from the cognizant NASA Technology Utilization Office and generate 
appropriate summaries for NASA Headquarters in cases where NASA graphical 
prototyping software is to be released to another organization. 

2.02 NASA shall contribute the following to the Agreement: 

i) source code for the current versions of the graphical prototyping tools on cartridge tape 
distribution medium; 

ii) text source (Macintosh file in Microsoft Word format) of current graphical prototyping 
tool documentation; 

iii) access to source code of any analysis tools to be used (or considered for use) in 
conjunction with graphical prototyping tools; 

iv) integration of the tools developed by <Organization> in 2.0 li) with existing tools 
utilized by NASA; 
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v) collaborate with <Organization> on the development of interfaces between the graphical 
prototyping tools and both existing and potential analysis tools; 

2.03 Each party will appoint a person to serve as an official contact and to coordinate the 
activities of each party in carrying out this Agreement. The appointees of each party are: 

<Organization>: <name/title> 

NASA: E. James Hartzell/Chief, Code FLI 

2.04 Each party shall have sole discretion with respect to implementation of the work done by it. 
Each party's use of the advice and comments offered by the other party is at the using 
party's sole discretion and risk. 

2.05 In performance of activities pursuant to this Agreement, it is contemplated that 
<Organization> and NASA personnel will visit and confer at the other's facilities, and 
therefore each party agrees to observe the safety, security and facility operating rules while 
on the other's property. 

2.06 Title to any personal property furnished by one of the parties to the other under this 
Agreement shall remain in the party furnishing the same. The parties agree to exercise due 
care in handling such property; however, each of the parties agrees to be responsible for 
any damage to its property suffered in the performance of this Agreement and to waive any 
claim against the other party for such damage, whether arising through negligence or 
otherwise. 

2.07 No member of or delegate to the United States Congress, or resident commissioner, shall 
be admitted to any share or part of this Agreement, or to any benefit that may arise 
therefrom; but this provision shall not be construed to extend to this Agreement if made 
with a corporation for its general benefit. 


ARTICLE III - DATA 

3.01 Data as used in this Agreement is defined to encompass information relating to the 
SUBJECTS which is in writing, on computer magnetic storage medium or proper other 
recorded or tangible form. Orally disclosed information is included only to the extent that 
the information, and any restrictions on disclosure of the same pursuant to this Agreement, 
are identified at the time of disclosure and later reduced to writing and transmitted by the 
disclosing party to the recipient party within one (1) month of the oral disclosure. 

3.02 Except for limitations expressly stated in this Article, all data exchanged pursuant to this 
Agreement may be used or disclosed by the receiving party without restriction. The parties 
agree to use the data responsibly and to give credit to each other where appropriate in any 
publications. Although reasonable efforts will be made by the parties to minimize such 
occurrence, it may be necessary for <Organization>, within its sole discretion, to furnish or 
otherwise disclose to NASA certain previously existing (relative to the date of this 
Agreement) data which constitutes <Organization> trade secrets. In order to enable 
<Organization> to maintain its trade secret rights in such data, the following Notice shall be 
affixed to the data and NASA will thereafter treat the data in accordance with the conditions 
of the Notice. 


NOTICE 
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This data is a trade secret of <Organization> and is submitted in confidence 
to NASA under Technical Exchange. It may be used, reproduced and 
disclosed by NASA only for the purpose of carrying out its responsibilities 
thereunder, with the express limitation that it will not, without prior written 
permission of <Organization>, be disclosed outside NASA. This Notice 
shall be marked on any reproduction of this data in whole or in part. 

Upon termination or expiration of this Agreement, NASA agrees to return all copies 
of trade secret data bearing such Notice to <Organization> or to destroy the same at 
the option of <Organization>. 

3.03 As to data newly developed by <Organization> pursuant to this Agreement and identified 
by <Organization> at the time of transmitting the same to NASA as related to an invention 
for which <Organization> wishes to seek patent protection, NASA shall, to the extent 
permitted by law, withhold such data from public disclosure for a reasonable period not to 
exceed one (1) year from the data of receipt thereof by NASA. Any such data and 
unrestricted data contained in the same document therewith shall be clearly designated by 
<Organization> with appropriate markings. 

3.04 No rights are granted to NASA by this Agreement in any <Organization> patent rights 
covering inventions disclosed in previously existing or newly developed data or other 
<Organization> information disclosed to NASA by <Organization> pursuant to this 
Agreement. 

3.05 Data newly developed by NASA pursuant to this Agreement and identified by NASA at the 
time of transmitting the same to <Organization> as related to an invention for which NASA 
wishes to seek foreign patent protection shall be withheld from public disclosure by 
<Organization> for a reasonable period not to exceed one (1) year. Newly developed 
NASA data shall also be subject to withholding from public disclosure by <Organization> 
in order to preserve first publication rights in the NASA employee investigator(s) who 
originated the data. Any such data and any unrestricted data contained in the same 
document shall be clearly designated by NASA with appropriate markings. 

3.06 Each of the parties shall have the right to disclose to third parties for purposes consistent 
with the purpose of this Agreement as define in Section 1.01, data originated by the other 
party, providing such third parties before receiving data shall agree in writing to be subject 
to the same restrictions on use and disclosure of data as are imposed on the party disclosing 
the data to the third party. 


ARTICLE IV - TERM OF AGREEMENT 

4.0 1 The term of this Agreement shall be for one (1) year from the effective data of this 
Agreement. 

4.02 This Agreement may be extended beyond its term pursuant to Section 4.01 by mutual 
written Agreement to the parties. . 

4.03 Either party may unilaterally terminate this Agreement prior to its expiration specified in 
Section 4.01 by giving written notice to the other party two (2) weeks prior to the desired 
termination date. Neither party shall be entitled to any compensation, or other form of 
consideration due to such termination, and neither party will be required to transfer any 
data, information, patents or other results of the work accomplished or in progress except 
as otherwise expressly provided in this Agreement. 
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4.04 


The obligations of each party pursuant to Article 2.06 and Article III survive (a) the 
expiration of this Agreement pursuant to Section 4.01 or (b) the termination of this 
Agreement pursuant to Section 4.03. 

4.05 The parties hereby execute this Agreement as of the date set forth below. 


<ORGANIZATION> NASA 

By: By: 

Title: Title: _ 

Dated: Dated: 
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POSITION: ILS MANAGER 
(Option 1) 

Industry Liaison Section 

Computation Human Engineering Office (Code FLI) 
Aerospace Human Factors Research Division 
NASA/Ames Research Center 


SUMMARY: 

The ILS Manager will initially serve as the only staff member in the ILS. Consequently, the ILS 
Manager must function in the capacity of liaison, technical lead and technical support until 
additional staff may be added. The ILS Manager's primary duties will be to establish contacts 
outside the Code FLI Office and promote collaborative relationships whereby information and 
technology may be optimally transferred between the FLI Office and other Government 
organizations, industry and academia. The ILS Manager will also be responsible for refining the 
ILS charter, subsequent staffing and conduct of ILS policy and procedures. 


DUTIES AND RESPONSIBILITIES 

Identify & Cultivate Candidates for MIDAS Technology 

Understand & Promote MIDAS Concept 

Understand Functional Limitations and Weaknesses 

Emphasize Problem Solving Capabilities Available Today 

Author and Present Technical Papers 

Disseminate New Data to Development Staff 

Generate & Document Technical Recommendations 

Produce Summary Reports & Functional Recommendations 

Provide Demonstrations as Required 

Interact with Program Office 

Serve as Program Office Representative as Required 

Develop and Track Contracts and Collaborative Agreements 

Establish and Maintain Contacts in Government, Industry and Academia 

Understand Technology Transfer Requirements 

Maintain Liaison w/Technology Utilization Office & NASA/HQ 

Develop and Refine ILS Policy and Procedures 

Staff or Assist with Staffing ILS as Required 

Enhance Public Relations 


QUALIFICATIONS 


REQUIREMENTS: 

Minimum BS in Technical Field 

Understanding of Man-Machine System Design Issues 

Strong Communication Skills 

Relevant Contacts in Government, Industry and Academia 
Technical Writing Skills 
Willingness to Travel 

Ability to Define Goals and Develop Work Plans 


65 


DESIRED: 


Familiarity with Programming 

Understanding of Specific Man-Machine System Design Problems 
Ability to Accomplish Work through Others 
Previous Visibility Outside NASA 
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POSITION: n.S TECHNICAL LEAD 
(Option 1) 

Industry Liaison Section 
Computation Human Engineering Office 
Aerospace Human Factors Research Division 
NASA/Ames Research Center 


SUMMARY: 

The ILS Technical Lead will be the point of contact for all MIDAS technical and implementation 
details. The Technical Lead will be responsible for technically assessing the suitability of MIDAS 
technology for specific user problems, and assisting users and potential users in the application of 
MIDAS to particular problem domains. The technical lead will also evaluate the applicability to 
MIDAS of existing or emerging technology outside Code FLI and will often be required to visit 
Government, industry or academia sites to study the technical details of their capabilities as well as 
their problems. The Technical Lead will initially be responsible for offloading the ILS Manager of 
detailed technical responsibilities to free the Manager to concentrate on exploring and developing 
collaborative arrangements. The Technical Lead will also perform critical technical support 
functions until the position is filled, and may assist the Manager in recruiting additional ILS staff as 
required. 


DUTIES AND RESPONSIBILITIES 

Maintain Technical Liaison w/Outside 

Study Technology of Like Efforts 

Disseminate New Technical Data to Development Staff 

Report Findings and Status as Necessary 

Generate & Document Technical Recommendations 

Configuration Management Procedures 

Maintain User & Programmer Documentation 

Software Submissions to COSMIC 

Guest Logistics (badging, orientation, setup, etc.) 

Distribution of Documentation, Reprints, Code, etc. 

Document MIDAS Usability /User Interface Feedback from Users 
Conduct User Surveys 

Thorough Understanding of MIDAS Implementation Details 
Devise Technical Recommendation Ranking Scheme 
Assist Visiting Staff w/MIDAS Modifications as Needed 


QUALIFICATIONS 


REQUIREMENTS: 

Minimum BS in CS or Engineering 

Minimum 2 Years Industry Experience 

C and LISP Programming Languages, Minimum 2 yr. 

Communication Skills 

Willingness to Travel 

DESIRED: 
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Applications Experience with Silicon Graphics and/or Symbolics Computers 

Prior Man-Machine System Design Experience 

Understanding of Typical Design Problems 

Technical Writing Skills 

Motivated, Self Starter 

Ability to Work with Others 



POSITION: TECHNICAL SUPPORT 
(Option 1) 

Industry Liaison Section 
Computation Human Engineering Office 
Aerospace Human Factors Research Division 
NASA/Ames Research Center 


SUMMARY: 

The Technical Support specialist will be responsible for ensuring all ILS software configurations 
and documentation are maintained. Temporary staff who are utilizing ILS MIDAS equipment will 
be the responsibility of the Technical Support specialist in terms of NASA badging, orientation and 
access to necessary working facilities. The Technical Support specialist will be responsible for 
configuration management and distribution of products outside Code FLI, including obtaining the 
necessary approvals prior to release. The Technical Support specialist will also serve as the bridge 
between users of MIDAS and the development staff by conducting and summarizing user surveys. 
Functional and/or technical recommendations may be provided as a product of such surveys, in 
cooperation with input from the Technical Lead. 


DUTIES AND RESPONSIBILITIES 

Maintain Configuration Management Procedures for Release Software & Documentation 

Recommend and Implement Documentation Standards 

Research and Implement Appropriate Software QA Practices 

Maintain User and Programmer Documentation 

Software Submissions to COSMIC 

Guest Logistics (badging, orientation, setup, etc.) 

Distribution of Documentation, Reprints, Code, etc. 

Document Usability/User Interface Feedback from Users 
Conduct and Compile Surveys 

Produce Summary Reports & Functional Recommendations 
Assist Visiting Staff w/MIDAS Modifications as Needed 


QUALIFICATIONS 


REQUIREMENTS: 

Minimum BS in Technical Field 

Systems Administration on UNIX and LISP Hardware 

Technical Writing Skills 

Ability to Take Direction from Others 

DESIRED: 

Applications Experience with Silicon Graphics and/or Symbolics Computers 
Oral Communication Skills 

C and LISP Programming Languages, Minimum 1 yr. 
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POSITION: ILS MANAGER 
(Option 2) 

Industry Liaison Section 

Computation Human Engineering Office (Code FLI) 
Aerospace Human Factors Research Division 
NASA/Ames Research Center 


SUMMARY: 

The ILS Manager will initially serve as the only staff member in the ILS. Consequently, the ILS 
Manager must function in the capacity of liaison, technical lead and technical support until 
additional staff may be added. The ILS Manager's primary duties will be to establish contacts 
outside the Code FLI Office and promote collaborative relationships whereby information and 
technology may be optimally transferred between the FLI Office and other Government 
organizations, industry and academia. The ILS Manager will also be responsible for refining the 
ILS charter, subsequent staffing and conduct of ILS policy and procedures. 


DUTIES AND RESPONSIBILITIES 

Identify & Cultivate Candidates for MIDAS Technology 

Understand & Promote MIDAS Concept 

Understand Functional Limitations and Weaknesses 

Emphasize Problem Solving Capabilities Available Today 

Author and Present Technical Papers 

Disseminate New Data to Development Staff 

Generate & Document Technical Recommendations 

Produce Summary Reports & Functional Recommendations 

Provide Demonstrations as Required 

Interact with Program Office 

Serve as Program Office Representative as Required 

Develop and Track Contracts and Collaborative Agreements 

Establish and Maintain Contacts in Government, Industry and Academia 

Understand Technology Transfer Requirements 

Maintain Liaison w/Technology Utilization Office & NASA/HQ 

Develop and Refine ILS Policy and Procedures 

Staff or Assist with Staffing ILS as Required 

Enhance Public Relations 


QUALIFICATIONS 


REQUIREMENTS: 

Minimum BS in Technical Field 

Understanding of Man-Machine System Design Issues 

Strong Communication Skills 

Relevant Contacts in Government, Industry and Academia 
Technical Writing Skills 
Willingness to Travel 

Ability to Define Goals and Develop Work Plans 
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DESIRED: 


Familiarity with Programming 

Understanding of Specific Man-Machine System Design Problems 
Ability to Accomplish Work through Others 
Previous Visibility Outside NASA 
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POSITION: n ,S TECHNICAL LEAD 
(Option 2) 

Industry Liaison Section 
Computation Human Engineering Office 
Aerospace Human Factors Research Division 
NASA/Ames Research Center 


SUMMARY: 

The ILS Technical Lead will.be the point of contact for all MIDAS technical and implementation 
details. The Technical Lead will be responsible for technically assessing the suitability of MIDAS 
technology for specific user problems, and assisting users and potential users in the application of 
MIDAS to particular problem domains. The technical lead will also evaluate the applicability to 
MIDAS of existing or emerging technology outside Code FLI and will often be required to visit 
Government, industry or academia sites to study the technical details of their capabilities as well as 
their problems. The Technical Lead will be responsible for offloading the ILS Manager of detailed 
technical responsibilities to free the Manager to concentrate on exploring and developing 
collaborative arrangements. The Technical Lead may also assist the ILS Manager in recruiting 
additional ILS staff as required. 


DUTIES AND RESPONSIBILITIES 

Maintain Technical Liaison w/Outside 

Study Technology of Like Efforts 

Disseminate New Technical Data to Development Staff 

Report Findings and Status as Necessary 

Generate & Document Technical Recommendations 

Document MIDAS Usability/User Interface Feedback from Users 

Conduct Technical Surveys as Necessary 

Thorough Understanding of MIDAS Implementation Details 

Devise Technical Recommendation Ranking Scheme 

Assist Visiting Staff w/MIDAS Modifications as Needed 

Assist Development Staff w/MIDAS Modifications as Time Permits 


QUALIFICATIONS 


REQUIREMENTS: 

Minimum BS in CS or Engineering 

Minimum 2 Years Industry Experience 

C and LISP Programming Languages, Minimum 2 yr. 

Communication Skills 
Willingness to Travel 

DESIRED: 

Applications Experience with Silicon Graphics and/or Symbolics Computers 
Prior Man-Machine System Design Experience 
Understanding of Typical Design Problems 
Technical Writing Skills 
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Motivated, Self Starter 
Ability to Work with Others 


POSITION: TECHNICAL SUPPORT 
(Option 2) 


Industry Liaison Section 
Computation Human Engineering Office 
Aerospace Human Factors Research Division 
NASA/Ames Research Center 


SUMMARY: 

The Technical Support specialist will be responsible for ensuring all ILS software configurations 
and documentation are maintained. Temporary staff who are utilizing ILS MIDAS equipment will 
be the responsibility of the Technical Support specialist in terms of NASA badging, orientation and 
access to necessary working facilities. The Technical Support specialist will be responsible for 
configuration management and distribution of products outside Code FLI, including obtaining the 
necessary approvals prior to release. The Technical Support specialist will also serve as the bridge 
between users of MIDAS and the development staff by conducting and summarizing user surveys. 
Functional and/or technical recommendations may be provided as a product of such surveys, in 
cooperation with input from the Technical Lead. 


DUTIES AND RESPONSIBILITIES 

Maintain Configuration Management Procedures for Release Software & Documentation 

Recommend and Implement Documentation Standards 

Research and Implement Appropriate Software QA Practices 

Maintain User and Programmer Documentation 

Software Submissions to COSMIC 

Guest Logistics (badging, orientation, setup, etc.) 

Distribution of Documentation, Reprints, Code, etc. 

Document Usability/User Interface Feedback from Users 
Conduct and Compile Surveys 

Produce Summary Reports & Functional Recommendations 
Assist Visiting Staff w/MIDAS Modifications as Needed 


QUALIFICATIONS 


REQUIREMENTS: 

Minimum BS in Technical Field 

Systems Administration on UNIX and LISP Hardware 

Technical Writing Skills 

Ability to Take Direction from Others 

DESIRED: 

Applications Experience with Silicon Graphics and/or Symbolics Computers 
Oral Communication Skills 

C and LISP Programming Languages, Minimum 1 yr. 
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